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Preface 


The  purpose  of  the  study  was  to  investigate  the  possibility  of  recovering  the  design  of  existing 
software  to  populate  a  reuse  library.  The  immediate  need  is  to  populate  the  Automatic  Program¬ 
ming  Technologies  for  Avionics  Systems  (APTAS)  library,  but  the  approach  used  should  be  valid 
for  general  library  population. 

There  were  many  people  that  helped  me  tremendously  throughout  this  project.  I  would  like 
to  express  my  appreciation  to  ray  sponsor,  John  Werthmann  from  Wright  Laboratories/ A  ART, 
for  allowing  me  the  opportunity  to  learn  and  discover  while  applying  school  studies  to  a  real- 
world  problem.  I  am  most  grateful  to  my  advisor,  Captain  James  Cardow  for  his  patience  and 
perseverance  in  his  efl'ort  to  lead  and  guide  me  in  'he  right  direction.  Finally,  many  thanks  and  my 
love  to  my  wife  Tami  for  her  concern,  pressure,  and  understanding  during  the  many  early  mornings 
of  study. 


Chester  A.  Wright,  Jr. 
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Abstract 

The  thesis  research  investigated  design  recovery  as  a  means  of  populating  a  reuse  library. 
The  targeted  library  was  part  of  the  Automatic  Programming  Technologies  for  Avionics  Systems 
(APTAS).  APTAS  uses  a  knowledge  base  of  forms,  to  present  questions  to  a  user,  and  rules,  to 
select  the  forms  to  present  and  choose  existing  library  modules  to  use  in  composing  a  new  system. 
The  approach  applied  the  reengineering  model  developed  by  Eric  Byrne  to  accomplish  planning  for 
the  project,  expanded  the  renovation  phase  of  this  model  to  cover  the  actual  design  recovery,  and 
applied  the  expanded  model  to  populating  the  library. 

Using  the  model  in  the  project  showed  that  design  recovery  is  feasible  in  populating  the 
library.  However,  if  the  recovered  design  could  not  be  used  directly,  it  could  be  used  as  a  guide 
in  developing  new  components.  Additionally,  certain  modules  make  better  candidates  than  others. 
Ideal  candidates  are  self-contained  in  that  they  receive  a  value,  perform  a  computation,  and  return 
a  value.  Once  the  module  starts  performing  too  many  operations,  expertise  is  required  in  the 
module  behavior  in  order  to  separate  the  component  for  reuse. 
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DESIGN  RECOVERY  FOR  SOFTWARE  LIBRARY  POPULATION 


/.  Introduction 


1.1  Background 

Developing  any  system  requires  defining  what  the  system  is  to  accomplish,  identifying  re¬ 
sources  required  to  build  the  system,  and  putting  the  resources  together  to  produce  the  desired 
product.  Once  the  system  is  in  existence,  it  is  used  for  the  intended  purpose,  except  during  periods 
when  the  system  requires  maintenance.  The  waterfall  model,  shown  in  Figure  1.1,  represents  all 
of  these  processes  as  phases  in  the  lifecycle  of  a  software  system.  The  analysis  phase  defines  the 
user’s  requirements.  Actions  in  this  phase  provide  a  detailed  description  of  the  problem  that  needs 
to  be  solved;  documents  information  flow  and  structure  in  the  current  environment;  and  describes 
hardware,  software  and  human  interfaces  as  they  will  exist  (16).  The  product  of  this  phase  is 
a  document,  called  the  program  specification,  listing  all  of  the  requirements  the  system  is  to  ac¬ 
complish.  Using  this  specification  as  input,  the  design  phase  translates  each  requirement  into  a 
software  representation  (16).  Additionally,  required  system  resources  are  identified.  The  output  of 
this  phase  is  the  design  document  outlining  the  necessary  software  modules  and  their  functionality. 
At  the  code  phase,  programmers  take  the  design  document  and  convert  each  module  into  a  form 
that  can  be  executed  on  the  computer  system.  During  test,  system  behavior  is  compared  with  the 
requirements  to  ensure  there  is  a  correct  correspondence.  Once  the  system  leaves  the  test  phase,  it 
passes  to  the  customer  and  is  used  and  maintained  as  necessary. 

Developing  software  using  the  waterfall  model  has  created  problems.  General  Randolph,  as 
quoted  in  (2),  summed  up  the  nature  of  the  problem  with  software  development  when  he  said 

“We’ve  a  perfect  record...:  we’ve  never  made  one  on  time  yet”. 

In  his  studies  of  software  development  problems.  Brooks  (6)  refers  to  work  by  Charles  Portman, 
manager  of  ICL’s  Software  Division.  Portman  initially  found  his  programming  teams  were  taking 
twice  as  long  as  expected.  When  this  slippage  pattern  appeared,  he  asked  his  teams  to  keep  careful 
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Figure  1.1.  Classical  Software  Lifecycle  Model 


logs  of  time  usage  and  found  the  teams  were  only  able  to  utilize  50%  of  the  work  week  as  actual 
programming  and  debugging  time.  Machine  downtime,  meetings,  paperwork,  company  business, 
and  higher-priority,  short,  unrelated  jobs  were  among  the  culprits  using  the  remainder  of  the  teams’ 
time. 

There  is  another  important  side  effect  that  results  from  spending  too  much  time  developing 
software.  Brooks  notes  that  often  the  product  is  obsolete  upon  (or  before)  completion.  He  refers 
to  this  as  one  of  the  woes  of  developing  software. 

Executable  specifications  and  automatic  program  generation  are  two  ideas  that  may  provide 
a  means  to  reduce  the  time  involved  in  the  development  of  software  as  compared  with  using  the 
classical  software  lifecycle  model.  When  these  ideas  are  combined  there  are  benefits  for  the  entire 
software  development  process. 

1.1.1  Executable  Specificatio;.!-  As  shown  in  Figure  1.1,  the  software  development  process 
has  many  phases,  and  usually  the  same  people  are  not  involved  in  each  phase.  The  only  expertise 
gu.aranteed  to  pass  between  phases  is  the  document  produced  at  the  end  of  the  phase.  If  the 
document  is  not  complete,  there  is  a  possibility  of  introducing  errors.  Additionally,  once  the 
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Figure  1.2.  Automatic  Program  Generation 


analysis  phase  is  complete,  the  customer  is  usutilly  not  involved  again  until  the  end  of  the  testing 
phase.  This  means  errors  or  misunderstandings  in  the  original  specification  are  propagated  through 
the  development  and  not  discovered  until  testing  or  operation.  Errors  not  found  until  this  phase 
are  more  costly  to  fix.  Putting  the  specification  into  a  form  that  could  be  executed  on  a  computer 
for  the  customer’s  benefit  would  allow  adjusting  the  specification  to  better  represent  the  customer’s 
needs.  This  fine  tuning  reduces  the  number  of  errors  passed  through  the  following  phase  by  catching 
problems  early.  Also,  the  customer  can  see  the  sj'stem  in  action  and  is  assured  that  the  right  system 
is  being  built. 

1,1.2  Automatic  Program  Generation  Lewis  (12)  describes  a  code  generator,  as  it  relates 
to  automatic  program  generation,  as  a  system  that  “...takes  a  programmer’s  inputs  in  the  form 
of  .some  abstraction,  design,  or  direct  interaction  with  the  system  and  writes  out  a  source  program 
that  implements  the  details  of  the  application.”  What  he  sees  as  inputs  to  the  system  are  ab¬ 
stractions  that  hide  the  coding  details.  This  distinguishes  code  generators  from  tools  that  simply 
provide  language  templates.  Using  this  definition  allows  simplification  of  the  software  development 
model  to  the  representation  presented  in  Figure  1.2.  The  number  of  phases  involved  in  the  soft¬ 
ware  development  lifecycle  has  been  reduced  leading  to  increased  programmer  productivity,  fewer 
translation  errors,  and  no  direct  maintenance  on  the  code.  Programmer  productivity  increases 
since  the  coding  phase  has  been  eliminated.  .\lso,  more  products  can  be  produced  since  it  is  only 
necessary  to  develop  requirements.  There  are  fewer  errors  since  there  are  fewer  people  and  fewer 
plijises  involved.  With  automatic  program  generation,  there  is  no  need  to  do  maintenance  on  the 
code  since  the  code  is  generated  from  the  analysis  abstractions.  The  abstractions  are  adjusted  and 
new  code  is  generated. 
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1.1.3  Combining  Executable  Specifications  and  Automatic  Program  Generation  Executable 
specifications  add  value  to  the  automatic  generation  of  code.  As  mentioned  above,  finding  errors 
early  niake.s  code  production  more  cost  effective.  Being  able  to  execute  the  specification  gives  the 
customer  the  opportunity  to  evaluate  system  operation  before  code  is  generated.  Also,  executable 
spec!fication.s  combined  with  automatic  code  generation  aids  maintenance.  In  typical  software 
maintenance  environments,  the  documentation  for  the  software  does  not  match  the  functionality 
of  the  software.  This  makes  it  necessary  to  analyze  the  software  to  gain  an  understanding  of  its 
functionality  before  performing  any  maintenance.  This  activity  must  be  performed  over  and  over 
each  time  there  is  a  need  to  change  the  software.  This  is  very  labor  intensive,  and  each  time  a  change 
is  made  the  documentation  bears  less  resemblance  to  the  code.  Using  the  combined  methods,  it 
is  not  necessary  to  do  maintenance  on  the  software.  The  specification  can  be  changed  and  the 
new  code  can  be  generated.  Now  the  documentation  always  reflects  the  status  of  the  code.  As 
mentioned  by  Arnold  (3),  if  the  intermediate  form  of  the  specification  is  available  for  manipulation, 
additional  documentation  can  be  generated.  These  could  be  items  such  as  flow  charts,  dataflow 
diagrams,  or  user’s  manuals. 

The  next  section  describes  a  system  that  has  been  developed  to  experiment  with  combining 
the  ideas  of  executable  specifications  and  automatic  program  generation  in  a  limited  domain. 

1.2  Automatic  Programming  Technologies  for  Avionics  Software  (APTAS) 

APTAS  is  a  system  owned  by  Wright  Laboratory  which  will  be  used  as  a  proof-of-concept  for 
executable  specifications  and  automatic  program  generation  for  avionics  systems.  APTAS  operation 
begins  by  taking  in  a  specification  for  an  avionics  tracking  system.  The  system  selects  software 
modules  from  an  internal  library  based  on  rules  in  the  system  knowledge  base.  Once  the  modules 
have  been  selected,  APTAS  can  simulate  the  behavior  of  the  tracking  system  under  development 
so  the  specification  of  the  system  can  be  tuned.  After  the  desired  behavior  is  rf^presented,  APTAS 
can  generate  the  Ada  code  for  the  system. 

APTAS  composes  modules  from  its  library  to  develop  the  new  system.  However,  the  current 
APTAS  library  is  not  extensive.  To  get  the  full  benefit  of  APTAS,  the  internal  library  must  contain 
a  large  selection  of  tracking  modules.  In  the  past  Wright  Laboratory  coded  modules  on  an  as-needed 
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basis.  Presently  they  have  modules  in  many  programming  languages.  Transforming  the  modules 
will  be  labor  intensive,  so  automation  of  the  transformation  will  be  looked  at  to  speed  the  task  in 
this  and  similar  situations. 

This  thesis  looks  at  design  recovery  as  a  means  for  transforming  existing  modules  to  fill 
the  libraiy.  Byrne  (7)  has  developed  a  new  reengineering  model  that  outlines  many  of  the  issues 
involved  in  accomplishing  the  task.  Both  design  recovery  and  Byrne’s  model  are  described  in  detail 
in  Chapter  2. 


1.3  Problem  Statement 

The  work  that  needs  to  be  accomplished  to  populate  the  library  can  be  divided  into  four 

areas. 

•  Identify  tne  intermediate  language  format  used  in  the  APTAS  library.  A  template 
will  be  designed  identifying  important  parameters  and  specifications  for  library 
modules. 

f  Characterize  sample  modules  that  need  to  be  placed  into  the  present  library.  This 
will  enta'l  identifying  parameters  required  by  the  modules,  identifying  values  that 
are  returned  by  the  modules,  learning  how  to  invoke  the  modules,  and  also  identi¬ 
fying  the  modules’  functionality. 

»  Outline  a  procedure  that  will  take  the  module  behavior  and  map  it  into  the  format 
of  the  template.  This  is  also  a  point  in  the  reengineering  process  to  consider 
redesign  of  the  existing  modules.  Ideally  the  mapping  will  produce  behavior  rules 
that  APTAS  can  use  as  part  of  its  module  selection  criteria. 

•  Implement  the  mapping  function  and  test  the  newly  derived  APTAS  functionality 
with  the  behavior  of  the  original  module.  It  is  hoped  that  the  conversion  procedure 
can  be  fully  automated. 


1.4  Assumptions 

Developing  a  mapping  process  is  dependent  upon  being  able  to  characterize  the  present  AP¬ 
TAS  knowledge  base  and  being  able  to  develop  a  template  in  the  intermediate  language  accepted 
by  APTAS.  It  will  also  be  necessary  to  characterize  modules  that  are  to  be  converted.  This  involves 
capturing  usage  information  and  parameter  data  for  each  module. 
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Figure  1.".  ’>esign  Recovery  for  Software  Library  Population 


1.5  Scope 

The  research  proposed  here  will  be  limited  to  detailing  the  renovation  phase  of  Byrne’s  model 
and  applying  the  model  to  the  reengineering  of  selected  tracking  modules. 

LG  Summary  of  Current  Knowledge 

This  thesis  effort  researches  the  possibility  of  using  design  recovery  as  a  method  for  software 
library  population.  This  process  is  presented  in  Figure  1.3.  Beginning  wich  existing  source  code,  a 
method  will  be  developed  to  capture  and  reconstruct  a  design  representation.  Two  important  issues 
in  design  recovery  are  determining  design  decisions  and  representing  the  design.  Design  decisions 
can  be  used  to  restructure  the  recovered  design.  This  can  be  done  to  increase  understandability, 
efficiency,  and  maintainability  of  the  software  and  the  design.  A  good  representation  choice  will  also 
aid  in  understanding  and  make  conversion  to  the  new  system  easier.  Also  considered  at  this  point 
is  adding  features  to  the  recovered  design.  Once  the  design  is  finalized,  it  must  be  converted  to  the 
new  form.  Since  APTAS  will  generate  new  systems  utilizing  its  software  library,  it  is  necessary  to 
produce  a  new  module  in  a  format  accepted  by  APTAS. 

This  research  will  not  be  concerned  with  changing  the  functionality  of  the  existing  software, 
so  the  design  will  not  be  restructured.  It  seeks  to  capture  the  design  as-is  and  represent  it  for  use 
in  APTAS.  Since  the  final  form  is  for  an  existing  system,  the  final  representation  issues  have  been 
decided.  However,  the  actual  mapping  process  must  be  addressed.  These  concepts  will  be  covered 
in  the  literature  review. 
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To  ensure  that  all  facets  of  the  work  aie  covered,  Byrne’s  (7)  reengineering  process  model  will 
be  used.  Byrne’s  paper  outlines  all  of  the  phases  required  for  a  reengineering  project.  It  details  the 
analysis  and  planning  phase  and  gives  good  criteria  for  deiermining  the  need  for  a  reengineering 
effort.  A  .nummary  of  his  model  is  presented  in  Section  2.2.1. 

1.7  Approach/Methodology 

The  thesis  effort  will  begin  with  a  survey  of  the  literature  to  uncover  present  design  recovery, 
automatic  program  generation,  and  reuse  efforts.  This  will  be  Allowed  by  studying  the  intermediate 
library  language  to  understand  its  structure  and  requirements.  A  general  study  of  the  C  language 
will  be  necessary  to  become  familiar  with  the  module.*  that  will  be  converted.  Once  this  is  complete, 
a  mapping  process  will  be  developed,  implemented,  and  tested. 

1.8  Materials  and  Equipment 

A  complete  APTAS  system  is  required  to  accomr'’’  ,h  this  research.  Additionally,  access  to 
the  internal  intermediate  language  formats  and  specific.\tions  are  critical. 

1.9  Sequence  of  Presentation 

The  next  chapter  presents  a  review  of  current  work  related  to  this  thesis  effort.  Chapter  3 
outlines  the  methodology  that  will  be  used  to  solve  the  problem  outlined  above.  Chapter  4  de¬ 
tails  implementation  of  tlo  methodology  and  Chapter  5  summarizes  the  results  of  the  research. 
Chapter  5  also  gives  recommendations  for  additional  work  in  the  research  area. 


II.  Literature  Review 


2.1  Introduction 

The  research  presented  in  this  thesis  looks  at  software  design  recovery  for  library  population. 
To  better  understand  what  is  being  proposed,  it  is  necessary  to  understand  how  this  fits  into  the 
broader  scheme.  At  the  outermost  level  of  this  research  effort  is  a  system  designed  to  automatically 
generate  other  syovems  (see  Figure  2.1).  It  accomplishes  the  generation  by  taking  in  a  specification 


Figure  2.1.  Overall  Thesis  Effort 


and  using  its  internal  composition  rules  to  select  available  modules  from  its  internal  component 
library  that  will  implement  the  specification.  Once  the  correct  collection  of  components  is  selected, 
the  automatic  system  generator  can  create  the  new  system.  In  its  present  configuration,  the  top 
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level  system  does  not  have  many  components  in  the  internal  library.  This  limits  the  types  of  new 
systems  that  can  be  produced. 

Prior  to  APTAS,  systems  were  constructed  using  the  specification  and  manual  refinement 
until  a  new  coded  system  existed.  As  a  result,  there  are  existing  software  components  but  in  many 
forms  and  languages.  This  research  focused  on  reengineering  to  make  existing  modules  available  for 
the  internal  library  of  the  top-level  system.  The  reengineering  effort  examined  the  components  as 
they  existed  with  the  intent  of  capturing  their  design  and  putting  the  design  into  a  form  accessible 
by  the  automatic  system  generator.  Automatic  generation  of  effective  systems  requires  a  large 
collection  of  library  modules.  Automation  of  the  reengineering  task  will  make  best  use  of  the 
automatic  system  generator. 

This  review  presents  current  research  efforts  on  reengineering  and  details  one  specific  pro¬ 
posal  by  Byrne  for  modeling  a  reengineering  project.  It  also  covers  automatic  system  generation 
with  emphasis  on  using  library  components.  One  specific  top-level  system,  called  APTAS,  and  its 
relationship  to  automatic  system  generation  and  library  population  is  defined  as  this  system  will 
be  used  as  the  testbed  for  the  research.  Finally,  the  direction  of  the  thesis  is  given. 

2.2  Reengineering 

In  any  area  of  study  confusion  results  when  everyone  has  their  own  terms.  For  the  field  to 
communicate  and  grow,  it  is  necessary  to  come  up  with  a  common  set  of  definitions.  Chikofsky 
and  Cross  (9:13-17)  have  baselined  the  field  by  defining  the  key  terms  associated  with  software 
reengineering.  They  begin  with  the  model  of  the  software  lifecycle  shown  in  Figure  2.2  and  give 
the  following  definitions: 

forward  engineering  the  traditional  process  of  moving  from  high-level  abstractions 
and  logical,  implementation-independent  designs  to  the  physical  implementation 
of  a  system. 

reverse  engineering  the  process  of  analyzing  a  subject  system  to  identify  the  system’s 
components  and  their  interrelationships  and  to  create  representations  of  the  system 
in  another  form  or  at  a  higher  level  of  abstraction. 

redocumentation  is  a  subset  of  reverse  engineering  that  creates  or  revises  a 
semantically  equival  nt  representation  within  the  same  relative  abstraction 
level.  The  resulting  forms  of  representation  are  usually  considered  alternate 
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Figure  2.2.  Relationship  Between  Terms  (9) 


views  (e.g.,  dataflow,  data  structure,  and  control  flow)  intended  lor  a  human 
audience. 

design  recovery  is  a  subset  of  reverse  engineering  in  which  domain  knowledge, 
external  information,  and  deduction  or  fuzzy  reasoning  are  added  to  the  obser¬ 
vations  of  the  subject  system  to  identify  meaningful  higher  level  abstractions 
beyond  those  obtained  directly  by  examining  the  system  itself. 

restructuring  the  transformation  from  one  representation  form  to  another  at  the  same 
relative  abstraction  level,  while  preserving  the  subject  system's  external  behavior 
(functionality  and  semantics). 

reengineering  also  known  as  both  renovation  and  reclamation,  is  the  examination  and 
alteration  of  a  sub  ject  system  to  reconstitute  it  in  a  new  form  and  the  subsequent 
implementation  of  the  new  form. 

Throughout  the  remainder  of  this  thesis  use  of  these  terms  will  be  with  the  meanings  given  here. 

2.2.1  Byrne’s  Model  Byrne’s  work  studies  the  process  of  software  reengineering.  His  goal 
is  to  determine  how  a  software  reengineering  project  can  be  accomplished.  He  poses  two  questions 
that  must  be  answered  for  any  reengineering  project:  what  information  must  be  produced  and  when 
can  this  information  be  produced.  The  answers  to  these  questions  determine  the  information  used 
by  the  process  and  determines  the  tasks  and  their  relationships  within  the  process.  Most  of  the 
present  work  in  reengineering  emphasizes  the  technical  aspects  that  must  be  resolved  (7).  It  turns 


out  that  technical  aspects  are  only  one  key  to  a  successful  project.  Byrne  has  identified  project 
management,  technical  work,  and  support  as  the  areas  that  control  the  entire  reengineering  process. 
As  shown  in  Figure  2.3,  these  processes  are  interwoven  and  must  be  handled  together  to  make  a 


Figure  2.3.  Control  Area  Relationships  (1) 


successful  project.  One  other  issue  Byrne  addresses  is  the  need  to  specify  the  reengineering  process 
unequivocally.  He  chose  the  specification  language  Z  to  overcome  the  problems  that  result  when 
English  is  used.  The  following  sections  give  an  introduction  to  Z  and  present  a  general  overview 
of  Byrne’s  model.  Also  covered  are  the  tasks  for  the  three  control  areas  previously  mentioned  and 
the  mapping  of  these  tasks  to  the  phases  of  a  reengineering  project. 

2. 2.1. 1  Introduction  to  Z  Z  is  a  language  fc.;  formally  specifying  computer  systems. 
It  uses  the  rnathematica’  concepts  of  set  theory  and  logic.  For  a  detailed  discussion,  see  (18).  What 
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is  presented  here  is  a  few  of  the  basics  to  allow  an  understanding  of  Byrne’s  model'.  The  basic 
feature  of  Z  is  the  schema,  and  it  has  the  following  form. 

I _ schema  —  name _ 

signature 


The  schema-name  allows  the  schema  to  be  included  within  other  schemas.  The  signature 
identifies  variable  names  and  their  types.  The  predicate  describes  relationships  among  the  variables. 
These  schemas  are  used  to  describe  states,  events  and  observations.  States  are  mathematical 
structures  which  model  a  system,  events  are  occurrences  of  interest,  and  observations  are  variables 
that  can  be  examined  before  and  after  an  event.  Here  are  two  example  scliemas. 


.  counter _ 

value  Jimii  :Af 


value  <  limit 


.  increment _ 

Acounter 

value'  =  value  +  1 
limit'  =  limit 


The  schema  on  the  left  represents  a  counter  state  space.  It  says  that  there  are  two  variables 
associated  with  the  counter,  its  value  and  its  limits  and  these  variables  are  natural  numbers  M. 
The  predicate  says  the  value  of  the  counter  must  always  be  less  than  or  equal  to  the  limit.  The 
increment  schema  represents  an  event  that  changes  the  counter.  Note  how  it  uses  the  name  of  the 
schema  on  the  left  and  the  use  of  A  to  signify  that  it  changes  the  schema.  Here  the  predicate  shows 
that  the  new  counter  value  value'  is  the  result  of  adding  one  to  the  present  counter  value  value. 
The  predicate  also  shows  that  there  is  no  change  in  limit. 

2.2. 1.2  Model  Overview  By  defining  a  model  for  the  process  of  reengineering,  Byrne 
clarifies  the  properties  of  information  objects  and  their  interrelationships  without  trying  to  capture 
the  variety  of  documents  involved  in  the  process.  At  this  level  people  can  concentrate  on  why  there 

'See  Appendix  C  for  a  complete  list  of  the  Z  symbols  used  in  this  research 


2-5 


MANAGEMENT 
Define  Approach 
C«lim4tion 

Define  Organisational  Structure 

Define  Project  Proceduree  and  Standards 

Identify  Reeourcca 

Plan  System  Transition 

Scheduling 

Identify  Tools 

Define  Acceptance  Criteria 

Conflict  Resolution 

Project  Authorisation 

Personnel  Management 


SUPPORT 

Configuration  Management 
Quality  Assurance 
Project  Tracking 


Figure  2.4.  Control  Areas  and  Interest  Items 


must  be  a  reengineering  effort,  what  is  expected  of  the  effort,  and  other  high-level  issues.  The  list 
of  tasks  he  defines  as  needing  to  be  addressed  for  each  of  the  reengineering  process  control  areas  is 
given  in  Figure  2.4. 


2.2. 1.3  Process  Phases  The  reengineering  phases  identified  by  Byrne  associate  the 
interest  items  from  Figure  2.4  with  points  in  the  reengineering  process  as  shown  in  Figure  2.5.  Each 
interest  item  is  marked  with  S,  M,  or  T  to  indicate  whether  it  comes  from  the  Support,  Management, 
or  Technical,  respectively,  control  area.  These  phases  cover  24  of  the  30  items.  Miscellaneous  tasks 
encompass  the  six  remaining  items.  These  are  the  things  that  don’t  fit  into  any  one  phase  or  must 
be  carried  on  throughout  the  project.^ 

•  configuration  management  (S) 

•  quality  assurance  (S) 

•  process  tracking  (S'* 

•  project  authorization  (M) 

•  personnel  management  (M) 

•  conflict  resolution  (M) 


'‘See  Byrne  (7)  for  a  complete  description  of  the  reengineering  model. 
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Syetem  Tran«ition 


2-6 


Figure  2.5.  Reengineering  Process  Phases 
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A  look  at  the  Z  specification  for  part  of  the  analysis  and  planning  phase  gives  more  insight  into  the 
power  of  a  formal  specification  language.  Byrne  takes  the  analysis  and  planning  phase  and  details 
it  in  Z.  As  Figure  2.5  shows,  this  phase  has  14  associated  tasks.  The  details  of  each  task  look 
very  similar  in  Z.  So  detailing  any  one  task  requires  specifying  the  domain  of  the  task,  specifying 
the  variables  required  to  model  the  task,  and  specifying  the  operations  available  for  that  task. 
Beginning  with  this  definition 

MOT  IV  AT  ION  =  set  of  all  possible  reengineering  motivations 
OBJ  EOT IV  E  =  set  of  all  possible  reengineering  objectives 

Byrne  develops  the  following  schema  called  the  project  definition  that  tracks  and  labels  all  reasons 
and  goals  for  the  reengineering  project. 

DEFINITION _ 

reasons  :  LABEL  •+♦  MOTIVATION 
goals  :  LABEL  OBJECTIVE 


The  initial  value  for  the  project  is  given  in  the  schema 

INITMIEFINITION _ 

DEFINITION 

reasons  =  0 
goals  =  0 


The  operations  identified  on  the 

Add-reason 

Delete-reason 

Get-reason 

List-reasons 


DEFINITION  schema  are 

Add-goal 

Delete-goal 

Get-goal 

List-goals 


and  they  each  represent  changes  and  operations  on  the  state  of  DEFINITION.  The  schemas  below 
show  the  specification  for  these  operations  with  respect  to  MOTIVATIONS.  The  specification  for 
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OBJECTIVE  \s  similar.  There  are  several  new  symbols  in  these  definitions:  ?  signals  a  variable 
used  for  input;  !  signals  a  variable  used  for  output;  and  '  signals  tlie  new  value  of  the  given  variable. 


_ Add  —  reason _ 

ADEFINITJON 
ml  :  MOTIVATION 
I'!  ;  LABEL 

I?  ^  dorn  reasons 

reasons'  —  reasons  U  {/?  h-  m?} 

goals'  =  goals 


_ Delete  —  reason _ 

ADEFINITION 
n : LABEL 

I'l  $  dom  reasons 
reasons'  =  {/?}  reasons 

goals'  =  goals 


_ Get  —  rcaaon__^_ 

^DEFINITION 

11  :  LABEL 

m!  :  MOTIVATION 

m!  =  reasons{ll) 


_ List  —  reasons _ 

-DEFINITION 
11 :  LABEL 

m:  P{LABEL  x  MOTIVATION] 

rn=  {i  :  LABEL-,  m  :  MOTIVATION  |  reo.')oni(/)  =  in} 

The  other  tasks  of  the  analysis  and  planning  phase  were  defined  similarly.  The  first  step  taken 
was  to  define  the  domain  and  the  variables.  The  second  step  identified  the  various  operations  that 
were  required.  And  the  final  step  specified  the  operations. 

2.2.2  Software  Design  Recovery  Two  essential  steps  in  recovering  a  design  are  understand¬ 
ing  what  went  into  a  design  and  representing  this  information.  This  section  covers  work  that  has 
been  done  in  design  recovery. 

2.2.2. 1  Categorizing  Design  Decisions  Rugaber,  Ornburn,  and  LeBlanc  (17)  derived 
a  method  of  characterizing  design  decisions  by  analyzing  programming  constructs.  They  note  that 
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during  program  development,  many  decisions  are  made.  Some  address  the  problem  domain  and 
how  it  should  be  viewed  and  modeled,  while  others  address  constraints  imposed  by  the  solution 
space,  including  the  target  machine  and  language.  The  categories  they  give  are  listed  below. 

composition  and  decomposition 
encapsulation  and  interleaving 
ge^ieralizatioii  and  specialization 
representation 
data  and  procedures 
function  and  relation 

They  examine  a  FORTRAN  program  and  come  up  with  the  following  examples  as  indications  of 
design  decisions. 

interleaving  program  fragments  to  accomplish  two  calculations  in  a  single  program 
section. 

representing  structured  control  flow  in  a  language  tiiat  does  not  support  them 
(e.g.,  Repeat- Until,  If-Then,  If-Thew-Else,  and  Ca.se). 

interleaving  by  code  sharing  the  Else  part  of  and  If-Then-Else. 

data  interleaving  by  reusing  variable  names  for  two  different  purposes. 

generalizing  interpolation  schemes 

variable  introduction  to  save  on  repeated  computation. 

generalizing  interval  computation 

representing  structured  control  flow 

program  architecture 

They  conclude  that  representing  design  decisions  will  be  a  major  factor  in  effective  reuse.  The 
ideal  representation  must  be  easy  to  construct  during  development  and  reconstruct  during  reverse 
engineering.  Also,  it  must  be  formal  enough  to  manipulate  automatically  and  must  be  capable  of 
representing  aU  levels  of  design  decisions. 

2.2. 2. 2  Calling  Hierarchy  Another  method  used  for  design  recovery  begins  by  de¬ 
termining  variable  declarations  and  the  respective  modules  (10).  The  next  step  is  to  find  the 
lowest-level  modules  in  a  calling  hierarchy.  These  are  the  modules  that  do  not  call  other  modules. 
This  is  repeated  for  each  level  until  a  tree-like  structure  has  been  developed  representing  the  calling 
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structure  of  the  design.  Lockheed  has  used  this  method  to  gain  code  understanding  before  group¬ 
ing  code  segments  into  Ada-like  structures.  An  additional  use  tliey  found  for  this  information  is 
identification  of  components  for  pop’ilation  of  a  software  repository. 

2.J  Automatic  System  Generation 

Present  methods  for  generating  systems  have  centered  on  two  methods:  generation  of  systems 
by  composing  components  and  generation  of  templates  from  a  specification.  Composing  from 
components  require.s  having  a  library  of  modules  available  and  liaving  a  process  for  searching  and 
selecting  components.  The  template  method  yields  a  skeleton  with  coding  details  that  must  be 
completed  by  hand.  Two  applications  are  presented  here  that  make  use  of  these  methods. 

2.3.1  The  Draco  Approach  Neighbors  (15)  researched  automatic  programming  using  an 
experimental  prototyping  system  called  Draco.  It  uses  a  domain  language  to  describe  programs  in 
each  different  problem  area.  A  problem  area  is  considered  a  domain.  Objects  and  operations  repre¬ 
sent  analysis  in'ormation  aborit  a  problem  domain.  Analysis  information  states  what  is  important 
to  incdel  in  the  problem.  This  type  information  is  reused,  Also  objects  and  operations  from  one 
domain  language  cf.n  be  modeled  by  objects  and  operations  from  other  domain  languages.  This 
relationship  represents  different  design  possibilities.  Design  information  states  how  the  problem  is 
to  be  modeled.  Design  is  reused  each  time  one  of  the  design  possibilities  is  used.  At  some  level  of 
development  an  executable  language  is  needed.  This  is  the  bottom  of  the  modeling  hierarchy. 

The  traditional  development  cycle  started  with  user  and  system  analyst  interaction  to  specify 
what  the  system  was  to  do.  This  specification  was  passed  to  the  designer  to  who  determined  how 
the  system  would  accomplish  the  specified  behavior.  Draco  adds  two  new  human  roles.  A  domain 
emalyst  examines  needs  and  requirements  of  similar  systems  (the  same  problem  area).  This  is  passed 
to  a  domain  designer  who  specifies  different  implementations  for  the  various  objects  and  operations 
in  terms  of  domains  already  known  to  Draco.  At  this  point  in  the  development^  the  system  analyst 
and  user  interact  considering  existing  domains  (analysis  reuse).  At  the  next  stage,  the  designer 
interacts  with  Draco  to  choose  a  particular  implementation  (design  reuse).  The  basis  of  the  Draco 
work  is  the  use  of  domain  analysis  to  produce  domain  languages  which  may  be  transjormed  for 
optimization  purposes  and  implemented  by  software  components,  each  of  which  contains  multiple 
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refinements  ed.ch  of  which  make  implementation  decisions  by  restating  the  problem  in  other  domain 
languages  (15:565-566). 

2.3.2  Issues  Biggerstaff  a.nd  Richter  have  researched  the  technologies  that  are  available  to 
address  reuse.  The  two  major  areas  they  came  up  with  are  composition  and  generation.  These 
categories  were  determined  from  the  nature  of  the  reused  items.  The  composition  group  is  distin¬ 
guished  by  having  atomic  units  that  are  ideally  unchanged  in  each  new  application.  Their  example 
of  this  type  of  reuse  is  the  Unix  pipe  that  allows  customizing  commands  by  taking  the  output  of  one 
command  and  sending  it  through  another.  Their  generation  group  is  characterized  by  two  types 
of  patterns:  code  patterns  and  transformation  patterns.  Examples  of  these  types  of  reuse  are  ar- 
plication  generators  and  transformation  systems.  The  former  reuses  its  own  internal  code  patter i. . 
across  the  generation  of  many  systems.  The  latter  reuses  internal  rules  during  the  transformation 
process.  In  both  cases  it  is  the  process  that  is  being  reused.  Their  assessment  of  reuse  is  that  there 
are  dilemmas  that  require  trade  offs,  there  are  operational  issues  to  address,  and  there  is  the  issue 
of  the  level  of  reuse. 

Within  the  dilemmas  trade  offs  can  be  seen  from  many  perspectives: 

applicability  versus  payoff  Technologies  that  are  very  general  have  a  much  lower 
payoff  than  systems  that  are  narrowly  focused. 

component  size  versus  reuse  potential  As  a  component  grows,  the  payoff  from 
reuse  increases.  However,  the  component  becomes  more  specialized  decreasing 
its  potential  for  reuse. 

cost  of  library  population  Usually  projects  are  budgeted  to  meet  short-term  goals. 

Large  initial  investment  for  potential  long-term  payoffs  is  not  seen  as  a  viable 
alternative- 

The  operational  issues  they  identify  are  finding,  understanding,  modifying,  and  composing 
components.  Finding  components  includes  finding  exact  matches  as  well  as  similar  components. 
Without  an  exact  match,  the  similar  components  can  be  used  in  developing  a  new  component. 
Understanding  a  component  is  important  to  using  it  correctly  and  even  more  important  if  the 
component  must  be  modified.  Modifying  components  allows  the  system  to  evolve.  They  identified 
com.posing  components  as  the  most  challenging  because  the  components  must  be  represented  as 
distinct  entities  with  specific  characteristics  and  at  the  same  time  as  a  composition  with  a  different 
characteristic. 
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The  level  of  reuse  can  either  be  code  or  design.  Code  reuse  has  been  successful  in  numerical 
computation  routines.  However  these  areas  are  narrow  domains  that  are  well-understood.  These 
domains  are  also  not  rapidly  changing.  Design  reuse  is  seen  as  an  alternative,  but  it  requires  further 
study.  If  designs  are  represented  in  programming  languages  the  designs  become  too  specific.  If  they 
are  represented  very  generally,  they  cannot  be  processed  in  machine  form. 

After  their  research  they  speculate  that  there  will  be  very  little  immediate  progress  because 
of  the  initial  investment  required.  Also  additional  research  is  required  to  overcome  the  design 
representation  issues. 

2.4  APTAS 

As  stated  earlier,  the  research  proposed  here  will  make  library  modules  available  for  a  system 
that  automatically  generates  programs  by  compo.sing  components.  Figure  2.G  is  an  APTAS  system 
diagram  which  emphasizes  the  interfaces  presented  to  the  user  during  development  of  an  application 
(referred  to  in  APTAS  as  a  pToject).  An  engineer  using  the  system  begins  defining  a  tracking 
aoplication’s  specification  in  the  taxonomy  summary  window.  It  contains  of  a  set  of  text  lines, 
each  representing  a  form.  The  forms  present  questions  using  the  dynamic  forms  interface.  A  form 
takes  numeric,  text  string,  exclusive  choice,  or  checklist  information.  By  answering  the  presented 
questions,  the  specification  is  developed.  The  number  of  entries  appearing  in  the  summary  window 
increases,  reflecting  the  effects  form  selections  have  had  in  pruning  the  taxonomy  tree  toward  a 
specific  architecture. 

When  the  forms  are  complete,  they  are  submitted  to  the  architecture  generator.  The  generated 
architecture  is  presented  in  the  graphical  user  interface  (GUI).  It  presents  a  graphical  representation 
of  the  generated  architecture  using  components  that  can  be  edited  to  provide  the  specification’s 
details  before  code  synthesis  takes  place.  There  are  four  types  of  icons  used  in  the  GUI:  a  box 
represents  a  module;  a  circle  represents  the  communications  interface  of  a  module;  a  diamond 
represents  the  interface  function  of  a  module;  and  a  triangle  represents  a  parameter  of  a  module. 
There  are  also  lines  representing  relations  between  the  modules.  A  sample  module  is  presented  in 
Figure  2.7. 
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Figur«  2.6.  APTAS  Organizational  Diagram  (13) 
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I'Ugure  2.7.  GUI  Representation  of  a  Module 


When  the  specification  has  been  completed  in  the  graphical  user  interface,  an  implementation 
may  be  generated  in  ClDL  by  pushing  the  Synthesize  button  on  the  APTAS  system  control  panel. 
CiDL  is  a  high  level  system  design  language  developed  at  the  Lockheed  Software  Technology  Center 
(LSTC)  as  part  of  LSTC’s  Software  Synthesis  project.  Once  the  ClDL  code  has  been  generated,  an 
equivalent  Ada  implementation  can  be  generated  by  pushing  the  Translate  button  on  the  APTAS 
system  control  panel.  The  behavior  of  the  generated  ClDL  and  Ada  tracker  implementations  may  be 
tested  by  invoking  the  Execute  button’s  menu  from  the  APTAS  system  control  panel,  then  selecting 
either  Run  ClDL  or  Execute  Ada.  When  a  selection  is  made,  the  code  will  begin  executing,  and  a 
window  will  be  displayed  showing  the  output  of  the  tracker.  The  output  is  simultaneously  written 
to  files  for  future  analysis  and/or  utilization  of  the  Run-Time  Display  program.  The  data  generated 
from  the  executing  tracker  may  be  presented  in  a  visual  display  (shown  in  Figure  2.P.).  If  the  user 
is  not  satisfied  with  the  test  results,  he/she  may  return  to  the  GUI  or  taxonomy  summary  window 
to  modify  the  specification  and  repeat  the  synthesis  and  test  processes.  The  tracking  taxonomy  and 
coding  design  knowledge  base  is  used  to  support  multiple  phases  of  the  specification  and  synthesis 
process. 

2.5  APTAS  Library  Population 

Extending  the  tracking  taxonomy  and  coding  knowledge  ba.se  entails  writing  ClDl  •mplemen- 
tations  of  primitive  modules,  rules  which  determine  when  the  primitive  is  appropriate  for  a  given 
application,  and  the  questions  to  present  to  the  user  which  will  elicit  the  information  needed  to 
evaluate  those  rules.  The  Cidl  module  construct,  used  to  define  the  reusable  primitive  software 
components  of  the  APTAS  knowledge  base,  defines  a  new  type  which  encapsulates  a  set  of  types, 
declarations,  and  functions.  A  module  type  declaration  includes  up  to  four  sections:  parameters, 
interface,  structure,  and  behavior.  Parameters  provide  the  generic  character  of  modules.  The  exact 
properties  of  each  instantiation  of  the  module  type  depend  on  the  parameter  values  provided  when 
the  instance  was  created.  A  sample  module  is  given  in  Figure  2.9.  The  interface  describes  which 
components  of  the  module  are  accessible  outside  the  module.  The  structure  section  contains  the 
local  declarations.  The  behavior  section  describes  the  processing  which  takes  place  each  time  the 
module  type  is  instantiated.  Instantiation  is  performed  by  a  call  to  the  module  creation  function 
which  is  generated  whan  the  module  type  is  compiled.  Adding  a  primitive  to  the  taxonomy  requires 
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Figure  2.8.  Run-Time  Display 


Figure  2.9.  Sample  ClDL  Module 


adding  the  appropriate  forms  information  and  module  selection  criteria.  These  steps  are  performed 
by  first  determining  where  the  new  primitive  module  fits  into  the  existing  taxonomy,  determining 
the  conditions  under  which  it  should  be  selected  for  a  particular  application,  and  adding  the  appro¬ 
priate  entry  to  the  list  of  available  modules.  The  next  step  is  to  determine  the  appropriate  forms 
and/or  questions  for  existing  forms  required  to  solicit  the  information  needed  to  evaluate  those 
conditions. 


2,6  Review  Summary 

This  chapter  has  presented  current  work  in  the  field  of  design  recovery  and  automatic  program 
generation.  There  was  also  a  summary  of  Byrne’s  reengineering  model.  This  research  will  use 
the  model  as  a  framework  to  capture  all  of  the  issues  that  need  to  be  addressed  in  outlining  a 
reengineering  project.  The  methods  of  design  recovery  and  automatic  program  generatim  will  be 
examined  for  a  solution  to  the  problem  of  populating  the  APTAS  library. 
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III.  Methodology 


This  chapter  outlines  the  two-step  approach  selected  to  solve  the  library  population  problem. 
The  first  step  entails  using  Byrne’s  reengineering  model  to  guide  the  project.  As  discussed  earlier,  a 
reengineering  project  involves  technical  issues  as  well  as  support  and  management  issues.  Byrne’s 
model  was  chosen  because  it  deals  with  all  of  these  issues.  With  his  complete  description  of 
the  analysis  and  planning  phase,  Byrne  has  a  good  foundation  for  determining  the  need  for  a 
reengineering  effort  and  the  resources  that  will  be  required  to  complete  the  project.  Additionally, 
the  amount  of  detail  in  the  model  will  ensure  that  all  issues  are  addressed  and  tracked.  A  major  part 
of  the  first  step  elaborated  the  renovation  phase  of  the  reengineering  model,  in  Byrne’s  notation, 
since  it  was  not  developed  in  detail  by  Byrne.  The  second  step  was  to  reengineer  the  existing 
software  in  the  new  form.  This  step  applied  the  concepts  of  the  first  step  serving  as  a  proof-of- 
concept  for  the  model  and  for  using  design  recovery  as  a  solution  to  the  library  population  problem. 
The  approach  taken  in  this  chapter  is  to  demonstrate  how  to  use  Byrne’s  model  by  applying  his 
specification  of  the  analysis  and  planning  phase  to  the  library  problem,  to  develop  the  renovation 
phase,  aud  finally  to  apply  the  model  to  the  library  problem. 

S.l  Analysis  and  Planning  Phase 

Byrne’s  original  work  in  this  phase  wa.s  done  using  Z.  This  language  ic  based  on  formal  logic 
and.  set  theory.  With  this  very  mathematical  foundation,  it  reduces  the  ambiguity  in  the  resulting 
model.  This  research  will  continue  using  Z  to  maintain  a  low  level  of  ambiguity.  An  added  benefit 
will  be  easier  enactment  of  the  model  should  that  become  necessary.  Refin^^^  is  an  example  of 
a  programming  language  that  could  be  used  to  enact  this  model  since  it  to  is  bzised  on  set  theory 
and  formal  logic. 

The  previously  defined  Analysis  and  Planning  phase  is  shown  in  Figure  3.1.  The  tasks  have 
.  been  identified  by  Byrne  and  represent  management  (M),  technical  (T),  or  support  (S)  issues.  Each 
task  has  associated  characteristics  that  must  be  tracked.  To  follow  these  characteristics  operations 
are  identified  for  each  task.  The  characteristics  are  represented  as  a  set  of  partial  functions.  This 
means  there  is  a  mapping  from  a  name  for  a  characteristic  and  the  associated  entry  for  the  particular 
characteristic,  bince  all  of  these  tasks  are  represented  as  sets,  they  have  common  operations  that 
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ANALYSIS  AND  PLANNING 


Determine  Motivations  and  Objectives  (T) 

Analyze  Environments  (T) 

Collect  Inventory  (T) 

Define  Approach  (M) 

Documentation  Planning  (T) 

Plan  System  Transition  (M) 

Define  Acceptance  Criteria  (M) 

Define  Project  Procedures  and  Standards  (M) 

Identify  Resources  (M) 

Identify  Tools  (M) 

Test  Planning  (T) 

Estimation  (M) 

Define  Organizational  Structure  (M) 

Scheduling  (M) 

Figure  3.1.  Analysis  and  Planning  Phase 

can  be  performed  on  them.  These  operations  are  add  an  item  to  the  set,  delete  an  item  from  the 
set,  list  the  items  in  the  set,  and  get  an  item  from  the  set  for  modification.  Here  is  an  example 
using  tlie  task  Determine  Motivations  and  Objectives  as  it  applies  problem  of  library  population. 

This  task  tracks  all  of  the  motivations  and  objectives  for  a  project.  The  Z  schemas  were 
identified  in  2. 2. 1.3  to  add,  delete,  get,  and  list  all  of  the  reasons  and  goals  for  any  project.  This 
particular  project  begins  with  the  DEFINITION  schema  showing  reasons  and  goals  as  empty  sets. 

DEFINITION _ 

motivationt{T)  :  0 
objectivei[T)  :  0 


The  T  signifies  that  the.se  are  technical  tasks  as  previously  defined.  As  motivations  and 
objectives  are  identified  for  the  project,  the  add  function  is  applied  to  each  of  these  tasks  to 
document  this  information.  The  resulting  schema  for  the  library  problem  is  shown  here. 
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DEFINITION - - - - - 

moiivationsiT)  :  { 

(motl  i^->  (there  are  existing  routines  that  implement  functions  that  are  also  required  in  the  new  system)), 
(mots  >"•  (the  new  system  does  not  have  sufficient  routines  to  be  effective)), 

(mot3  (the  existing  routines  are  implemented  in  many  prograimning  languages)), 

{moH  i->  (the  existing  routines  are  spread  over  many  computers)), 

(mots  i-r  (the  existing  routines  are  ad  hoc;  appear  to  be  only  home  grown  utilities)), 

(mo<6  (there  is  incentive  to  lake  advantage  of  existing  routines  in  a  new  technology  that  generates 
Ada  code  from  tracking  algorithms)) 

} 

objectivts^T)  :  { 

(o&j  1  4->  (to  make  additional  routines  available  for  automatic  system  generation)), 

{obj2  t~»  (to  improve  software  system  maintainability)), 

(oij3  t-t  (to  convert  the  existing  library  to  a  single  language  that  can  be  used  to  generate  Ada)), 

{obj4  (to  port  the  existing  software  to  a  single  system)) 

) _ 

Application  of  the  Z-defined  operators  to  the  other  tasks  is  similar.  As  pointed  out  in  (8),  a 
major  output  of  the  analysis  part  of  this  phase  is  the  current  status  of  the  system.  The  planning 
part  of  this  phase  outlined  the  management  issues  including  identifying  the  scope  of  the  work,  the 
required  resources,  milestones,  and  establishing  a  schedule.  The  physical  outputs  of  this  phase  are 
an  overall  project  plan,  a  plan  for  the  other  phases,  and  the  existing  documentation.  The 

renovation  phase  is  one  of  the  phases  that  follows  analysis  and  planr 


S.2  System  Renovation  Phase 

At  this  phase  the  existing  system  is  transformed  into  the  target  syst^  'his  transformation 
follows  the  steps  outlined  in  (8).  There  are  five  tasks  used  to  accomplish  these  steps. 

•  Source  Code  Analysis 

•  Design  Recovery 

•  Information  Inspection 

•  Redesign 

•  Reimplementation 

This  section  details  these  tasks  using  Z.  This  phase  begins  with  some  of  the  outputs  from  the 
analysis  and  ple.nning  phase.  Additional  inputs  required  for  this  phase  are  existing  standards. 
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These  standards  are  items  required  of  all  projects.  Considering  the  first  two  tasks  together  forms 
reengineering  as  defined  earlier.  The  items  produced  by  these  tasks  include  a  data  dictionary  and 
a  cross  reference  of  all  files  and  variables.  Since  this  task  is  starting  with  source  code,  the  initial 
issue  would  consider  capturing  a  software  design-level  representation. 

S.2.1  Background  In  his  original  definition  of  the  model,  Byrne  defined  some  global  sets 
that  contained  items  used  in  every  phase  of  'i  J  project.  This  section  reviews  these  definitions 
since  they  will  be  used  as  part  of  the  description  of  the  schemas  and  operations  of  the  tasks  found 
in  the  renovation  phase.  Dates,  names,  labels,  and  conditions  are  used  extensively  throughout 
the  project.  Dates  are  associated  with  task  starts  and  stops  as  well  as  phase  starts  and  stops  for 
example.  Names  are  assigned  to  personnel,  files,  and  tasks.  Labels  could  be  associated  with  steps 
in  a  procedure  or  items  in  a  collection.  Finally,  conditions  are  used  to  signify  whether  or  not  things 
can  occur.  To  keep  track  of  dl  of  these,  four  sets  have  been  created. 


DAT  £  s  tet  of  all  valid  datei 
NAME  =  set  of  name* 

LABEL  s  set  of  all  labeU 
CONDITION  =  set  of  all  conditions 


Similar  to  the  idea  of  sets  to  represent  common  items  is  the  need  to  represent  lists  of  charac¬ 
teristic.  For  this  Byrne  identified  the  PROPERTY-LIST.  It  is  used  to  track  named  properties  and 
and  the  associated  values.  He  starts  by  identifying  all  properties  and  ail  values  as  sets. 

PROPERTY  =  set  of  all  properties 
VALUE  =  set  of  all  properly  vtdues 


Once  an  item  has  been  identified  as  having  many  properties  that  need  to  be  tracked,  a 
property  list  can  be  created  associating  a  collection  of  property  names  with  a  collection  of  property 
values.  Here  PROP-NAME  and  PROP-LIST  are  specified  and  the  initial  value  of  the  property  list 
is  given. 

PROP^ AM E  =  set  of  all  properly  names 
PROPJ^AME  C  NAME 
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PROP-LIST  :  PROP-NAME  ■**  VALUE 
INITIAL-PROP-LIST  =  0 

For  the  general  property  list,  referred  to  as  pi  below,  the  operations  add,  update,  delete, 
get,  and  list  are  defined.  These  operations  can  be  instantiated  for  any  list.  A  A  before  the  list 
name  indicates  that  the  list  changes  after  an  operation,  and  a  E  before  the  name  indicates  that  the 
operation  does  not  cause  a  change  in  the  list  composition.  The  add,  delete,  and  update  operations 
cause  changes  in  the  list,  while  the  get  and  list  do  not  cause  changes.  The  general  form  of  these 
operations  are  given  here. 


_ Add  —  Properly _ 

APROP-LIST 
p?  :  PROP-NAME 
ti?  :  VALUE 

p?  (  dom  pi 

pi'  =  pi  U  {p?  !-►«?} 


_ Update  —  Property - 

APROP-LIST 
pi  ;  PROP-LIST 
v1 :  VALUE 

pi  €  dom  pi 

pi' s:  p/®  {p?  !-►  v?) 


_ Delete  —  Property 

APROP-LIST 
pi  :  PROP 

pi  €  dom  pi 
pi'  =  {p?}  <pl 


_ Get  —  Property _ 

EPROP-LIST 
pi  :  PROP-NAME 
v! :  VALUE 

pi  G  dom  pi 

w!  =  p/(p?) 


_ List  -  Properties _ 

EPROP-LIST 

listl  :  P{PROP-NAME  x  VALUE} 

list]  =  {p  :  PROP-NAME-,  v  :  VALUE  \  pl(p)  =  t>} 


Knowing  the  basic  definitions  will  aid  in  understanding  the  definitions  to  follow.  The  first 
task  in  the  renovation  phase  is  source  code  analysis. 
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3.2.2  Source  Code  Analysis  The  input  to  this  task  is  the  existing  software  and  outputs  are 
source  code  information  and  a  data  dictionary.  To  capture  the  source  code  information  we  assume 
it  is  contcuned  in  one  or  more  files  having  similar  properties.  Analysis  proceeds  from  the  level 
of  identifying  files  down  through  identifying  procedures  and  functions,  subroutines,  and  variables. 

The  reason  for  following  this  pattern  is  that  it  structures  the  analysis,  and  it  follows  the  pattern 
used  by  people  going  from  the  general  to  the  specific.  The  collection  of  files  is  defined  as 

FILES  =  set  of  all  possible  project  files 

Each  file  has  a  name  that  is  a  member  of  iV/lMjE’ previously  identified.  The  specific  names  used  for 
files  will  be  denoted  FILE_NAME. 

FILEU^ AME  =  set  of  all  possible  file  names 
FILEJ^AME  C  ^A^{h 

Each  file  has  many  properties  associated  with  it.  For  files  that  are  to  be  converted  to  the  new 
system  information  that  must  be  collected  includes  the  location  of  the  fi-c^  the  type  file  (e.g.  input 
data  or  binary  output),  the  language  used  in  the  file,  the  names  of  files  that  use  it,  the  names  of 
other  files  that  it  uses,  and  the  contents  of  the  file.  Since  this  information  should  be  collected  on 
each  file  a  property  list  is  setup  to  ensure  complete  collection  of  information  for  each  file. 

FILE^^ROPERTIES  =  Predefined  set  of  all  file  properties 
FILEJ^ROPERTIES  C  PROP^LISTS 

At  this  point  in  the  reengineering  effort,  it  is  necessary  to  track  all  of  the  files  needed  by  the 
project.  The  schema  PROJECT-FILES  is  defined  to  track  these  items. 

^.PROJECT  J'lLES _ 

fileJist  ;  F  FILE-NAME 

/i7e_in/o  :  FILE-NAME  PROPJLISTS 
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Once  the  files  have  been  identified,  file  contents  can  be  analyzed.  Within  the  files  items 
that  are  expected  are  procedures,  functions,  subroutines,  and  variables.  Each  of  these  also  have 
properties  associated  with  them.  Procedures,  functions,  and  subroutines  are  similar  in  nature  and 
require  tracking  of  information  such  as  the  item  name,  the  functionality  provided  by  the  item, 
parameters  required  by  the  item,  expected  results,  the  typo  item,  where  it  is  declared,  and  where 
the  item  is  used.  Variables  require  tracking  information  such  as  the  name  of  the  variable,  its  type, 
where  it  i.s  declared,  where  it  is  used,  and  its  purpose.  Two  new  collections  are  identified  to  track 
the  names  of  these  items 

ROUT INES  =  set  of  all  possible  project  procedures,  functions,  and  subroutines 
VARIABLES  =  set  of  all  possible  project  variables 


and  property  lists  are  established  to  track  the  associated  properties. 


ROUTINE-I^ROPERTIES  =  Predefined  set  of  aU  routine  properties 
V AP-IABLE^ROPERT lES  =  Predefmed  set  of  al'  variable  properties 

ROUTINEJPROPERTIES  C  PROP-LISTS 
VARIABLE-PROPERTIES  C  PROP-LISTS 


Fiiictlly,  schemas  are  created  to  characterize  the  routines  and  variables, 

PROJECT-ROUTINES _ 

routincJiat  :  F  ROUT  IN  EJ^  AM  E 

Toutine-injo  :  ROUTINE AM E  PROP-LISTS 


-PROJECT-VARIABLES _ 

vaTiable-list  :  F  V  ARIABLE—N  AM E 
variable-irifo-.  VARIABLE-NAME  ■*>  PROP-LISTS 


The  data  dictionary  produced  in  forward  engineering  defines  all  of  the  data  used  in  the 
system  being  developed.  Reengineering  using  the  above  definitions  recovers  all  of  the  original  data 
definitions  from  the  existing  system.  In  addition  it  identifies  the  incidental  variables,  procedures, 
subroutines,  and  functions  and  shows  all  of  the  relationships  between  these  items.  Once  the  files, 
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routines,  and  variables  have  been  identified,  it  is  time  to  proceed  to  the  next  level  in  reengineering 
the  system;  Design  Recovery. 


3.2.3  Design  Recovery  Tii;s  task  of  the  renovation  phase  adds  domain  knowledge  and 
external  information  as  pointed  out  in  the  definition  of  design  recovery.  A  major  portion  of  this 
task  is  providing  the  information  that  links  the  items  identified  in  the  previous  task.  This  task  may 
provide  additional  information  for  the  present  property  lists  or  identify  additional  properties  that 
need  to  be  included  in  the  lists.  Also  identified  are  more  of  the  what  is  being  accomplished  by  the 
system  that  is  being  reengineered. 

Something  that  surfaces  at  this  point  in  the  reengineering  project  is  how  to  represent  the 
recovered  design.  There  are  many  tools  that  can  be  used  such  as  structure  charts,  transition 
diagrams,  and  program  description  languages.  It  docs  not  seem  that  any  one  tool  is  overall  better 
than  any  other.  However,  choosing  a  tool  based  or.  the  de.sired  oatcome  does  help.  A  hypertext 
tyj'e  tool  (5)  that  allows  multiple  views  of  the  same  information  seems  to  be  ideal.  This  would  allow 
viewing  the  'nformation  at  a  level  of  abstraction  on  par  with  the  task  at  hand.  The  specific  tool 
that  is  used  to  capture  design  information  is  something  that  should  be  outlined  in  the  standards  of 
the  organization  involved  in  the  reengineering  project.  What  is  defined  here  is  a  way  to  track  the 
proaucts  for  a  particula;  project. 

Individual  products  will  have  names  to  distinguish  them  from  other  items.  It  is  also  necessary 
to  t’  ack  their  location  and  details.  Here  details  refers  to  the  composition  of  the  product  whether 
they  are  diagrams  or  descriptions.  Since  any  project  can  have  multiple  design  products,  a  method 
is  needed  to  track  items  associated  with  a  particular  project.  The  definitions  necessary  to  carry 
out  these  tasks  are  identified  below. 

DESIGN  PRODUCT  —  set  of  all  r  ossible  design  products 

PROJECT  S  set  of  oU  possible  reengineering  projects 


DE.'ilGN PRODUCT-NAME  =  set  of  all  possible  design  product  names 
PROJECT— NAME  =  set  of  all  possible  project  names 

DESIGN^  PRODUCT-NAME  C  NAME 
PROJECT-NAME  C  NAME 
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^PROJECT-DESIGN _ 

project-name  :  F  PROJECT 

project-info  :  PROJECT  -  DESIGN -PRODUCT-N AM E 


The  recovered  design  is  now  ready  for  passing  to  the  next  task  in  the  renovation  phase. 

3.2.4  Information  Inspection  and  Redesign  In  the  information  inspection  task  the  details 
of  how  to  achieve  the  objectives  are  addressed.  The  output  produced  is  a  plan  for  changes  to  the 
recovered  design  to  get  the  new  design.  This  plan  will  probably  be  in  the  form  of  steps  that  need  to 
be  accomplished.  Since  the  recovered  design  has  created  artifacts  similar  to  those  used  in  forward 
engineering,  the  same  methods  could  be  used  to  plan  redevelopment  of  the  system. 

The  redesign  task  of  the  renovation  phase  allows  for  adjustments  to  the  de.sign  to  aid  future 
maintenance  of  the  system.  Also,  this  is  the  point  in  the  project  where  improvements  and  new 
requirements  could  be  added  to  the  system.  As  pointed  out  in  (8),  there  is  an  iterative  relationship 
between  these  two  tasks.  Changes  to  the  design  require  additional  planning  which  may  result  in 
additional  changes  to  the  design.  Therefore,  a  method  is  needed  to  track  all  of  the  changes  that 
occur  during  these  two  tasks. 

The  go:d  of  this  project  is  to  evaluat®  the  concept  of  library  population.  Since  the  modules 
that  will  be  transformed  are  assumed  to  exhibit  the  required  behavior,  redesign  will  not  play  a 
part  in  this  reengineering  effort-  This  pha.se  of  the  reengineering  model  will  not  be  used  for  this 
particular  project.  However,  if  population  seems  viable,  this  step  must  be  reexamined. 

3.2.5  Reimplementation  Reimplementatior.  is  the  phase  that  actually  produces  the  new 
system.  Once  progress  has  reached  this  phase,  traditional  forward  engineering  methods  can  continue 
to  be  used.  What  is  also  necessary  is  a  method  to  ensure  that  all  required  recovered  behavior  is 
implemented.  Part  of  this  task  is  unit  testing.  With  the  test  plans  that  have  been  developed  and 
the  behavior  that  has  been  noted  in  the  previous  tasks,  this  should  make  verification  of  proper 
behavior  easier. 


I 
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Now  that  the  tasks  have  been  outlined  for  the  library  population  problem,  they  can  be  put 
to  the  task  at  hand.  The  next  section  looks  at  developing  the  items  called  for  in  a  reengineering 
project. 

S.3  Library  Population 

At  this  point  in  the  research,  it  is  necessary  to  obtain  actual  modules  that  need  to  be  trans¬ 
formed.  Appendix  D  lists  the  first  module  selected  for  the  transformation.  It  is  not  too  large  and 
is  used  m  several  places  in  the  new  system.  All  of  the  source  code  is  contained  in  one  file,  however, 
the  module  produces  several  output  files  and  has  several  variables  and  subroutines.  What  follows 
is  a  description  of  the  information  recovered  as  a  result  of  applying  the  various  Z  definitions. 

S.3.1  Source  Code  Analysis  This  task  is  started  by  identifying  the  files  associated  with  this 
task.  Since  this  task  will  analyze  the  existing  source  code,  properties  are  then  identified  to  guide 
the  collection  of  information.  The  first  level  of  analysis  is  with  the  files  involved.  These  are  the 
properties  identified  with  information  to  be  gathered  about  each  file  in  the  collection  of  files. 

FILB-PHOPERT IBS  =  {location,  type,  language,  u$ei-filtt,  uted^in,  contents} 

After  the  specific  properties  are  identified,  this  is  compared  with  the  list  of  related  files  and  produces 
the  following  schema. 
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PROJECT-FILES _ 

/ileJist  !  ( 

EPSILON. PRK,KALMAN.PL,KALM  AN. PLT,Pn.PRN,Pn.PRN,XEST.PRP 
XMEAS.PRN,XNOISE.PRN,XTILDE.PHN.XrRUTII.PnN.YEST.PRN,YMEAS.PRN 
YNOISE.PRN.YTURTH.PRN.ZXNOISE.PRN,  ZYNOISE.PRN.projl.JoT 

} 

file-info  ;  { 

(EPSILON.PRN  >-•  (name  directory,  outiiut,  ASCII,  N/A,  N/A,  data  to  be  printed)), 
(KALMAN.pl  »  (same  directory,  output,  ASCII,  N/A,  N/A,  data  to  be  printed)), 
(KALMAN.PLT  •->  (same  directory,  output,  ASCII,  N/A,  N/A,  data  to  be  printed)), 

(Pll.PRN  >-4  (same  directory,  output,  ASCII,  N/A,  N/A,  data  to  be  printed)), 

(P22,PRN  e-t  (same  directo'y,  output,  ASCII,  N/A,  N/A.  data  to  be  printed)), 

(XEST.PRN  i->  (same  directory,  output,  ASCII,  N/A,  N/A,  data  to  be  printed)), 
(XMEAS.PRN  (same  directory,  output,  ASCII,  N/A,  N/A,  data  to  be  printed)), 
(XNOISE.PRN  (same  directory,  output,  ASCII,  N/A,  N/A,  data  to  be  printed)), 
(XTILDE.PRN  (same  directory,  output,  ASCII,  N/A,  N/A,  data  to  be  printed)), 
(XTRUTH.PRN  >->  (ssune  directory,  output,  ASCII,  N/A,  N/A,  data  to  be  printed)), 

(Y EST.PRN  !-•  (same  directory,  output,  ASCII,  N/A,  N/A,  data  to  be  printed)), 
(YMEAS.PRN  !-» (same  directory,  output,  .ASCII,  N/A,  N/A,  data  to  bo  printed)), 
(YNOISE.PRN  H*  (same  directory,  output,  A.SCIl,  N/A,  N/A,  data  to  be  printed)), 
(YTURTH.PRN  >-*  (same  directory,  output,  ASCII,  N/A,  N/A,  data  to  bo  printed)), 
(ZXNOISE.PRN  (same  directory,  output,  ASCII,  N/A,  N/A,  data  to  be  printed)), 
('ZYNOISE.PRN  >-*  (same  directory,  output,  ASCII,  N/A,  N/A,  data  to  be  printed)), 
(projl.for  (same  directory,  main  routine,  FORTRAN,  N/A,  N/A,  subroutines  and  variables)) 

} 


Source  code  analysis  continues  by  looking  into  the  various  files.  In  this  inslaaice,  the  only  file  that 
needs  to  be  examined  is  projl.for  since  all  of  the  other  files  are  produced  by  executing  this  file. 
This  portion  of  the  analysis  is  looking  for  procedures,  functions,  subroutines,  and  variables.  Again, 
the  first  step  is  defining  the  properties  that  need  to  be  collected  for  these  items.  Something  that 
comes  up  at  this  point  is  the  hierarchical  manner  of  declaring  procedures  and  variables.  They  can 
be  declared  in  one  place  and  used  in  another.  Usage  can  be  at  a  different  level  than  the  declaration. 
This  requires  the  usage  level  to  also  be  captured.  To  accomplish  this,  usage  will  be  represented  as 
file/procedure/.  ../procedure  until  the  proper  level  is  reached.  The  first  level  is  represented  by  the 
file  in  which  usage  occurs.  Procedures  or  subroutines  are  added  for  each  corresponding  level.  In 
defining  this  information,  scoping  rules  are  necessary.  The  procedure  used  for  scoping  is  to  identify 
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routines  and  variables  that  are  one  level  down  from  the  routine  of  interest.  The  following  properties 
are  identified  for  collection. 

ROUTINEU^ROPERTIES  =  {function,  pitrametert,  rciulU,  type,  dedarcdJn,  usecUn} 

VARIABLE  J'ROFERTIES  =  {type,  dedAredJn,  usedJn,  purpoie} 

Collecting  the  variable  and  routine  information  results  in  the  following  schemas, 

PROJECT-ROUTINES _ 

routtneJi.it  :  {nutin,  noise,  mtXL  .ul.  inlxtidd,  mlxsub,  nitxzro,  mtxtrp,  mtxinv,  idemtx} 
roulinejn/o  :  { 

(main  m  (k&lman  Alter  iniplementaticn,N/A,creAtei  AJes,proceduTe,/proJI.for,N/A)], 

(noise  (generates  gaussiau  noise, (xinean,  variance,  rndron,  n), 

matrix  initialized  with  noise,subroutine,/projl.for,/projl. for/ main)), 

(mtxmuJ  ■->  (matrix  multiplication,  (a,b,c,nl,n3,n3),  a'*b,subroutino,/pit>jl.ror,/projl.for/inain)), 

(mixaddt-t  (matrix  addition,  (a,b,c,nl,n2),a+b,subroutine,/projl.for,/projl.for/main)), 

(mixiub  (matrix  aubtractian,(a,b,c,nl,n2),a-b,subrautine,/prujl.for,/projl.for/main)), 

(mixtro  >-•  (matrix  zero,  (a,nl,n2),a,aubroutine, /projl.for,/projl.for/maln)), 

{mtxtrp  >->  (matrix  transpose,  (a,b,ln,n2),b,subroutine,/projl.for,/prujl.for/ntain)), 

(mtxinv  r-  (matrix  inverse,  (a,ainv,b,kc,is),  (ainv,ls),subioutine,/projl.fur,/projl.ror/main)), 

(ictemti;  (Identity  matrix,  (a,n),  aisubroutine,  /projl.for,/projl.ror/main)) 
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project^variahibs - 

voria6i««jiit  :  { 

K,  C,  n,  13.  IS.  lOPT,  NOR,  NHT.  X,  Y»  WX.  WY.  XHATN,  XHATOLD, 

VX,  VY,  Z,  XHAT,  2UAT,  NU,  P,  F,  FT,  R,  PN,  TKMPl,  TEMPS.  Q,  H,  S, 

HT,  SI,  W.  WT.  XTILDE,  XTILDET,  EPSILON.  Cf4ph.  PI.  N*ine( 

) 

variabi«^n/«  :  { 

(/v  i-»  (inU|«r,  /pioJl.for/mAin,  /proji.(or/u4in,  loop  couour)). 

(C  H*  (InltRfr.  /proJI.Ior/mMn,  /proil.Ior/mMn,  oompU  counUr)}. 

(/I  ^  (IntoRor.  /projl.for/moln,  /proJl  (or/ntaln. 

(/3  H>*  (inttgor,  /projl.for/inoln,  /proJl.for/moiA.  «o«d)). 

(/5  (inug^r,  /projl-for/moln,  /projl  for/moift,  moirU  «lngu!*r  fiA|)), 

{lOPT  (intogor,  /projl.for/rnoln,  /projl.for/nt4la,  putp)), 

{SOH  (Inugor,  /proil.Ior/moln,  /proil.foi/mMn.  pttrp))> 

{NPT  (iutogor,  /projl.ior/moin,  /pro}l.foir/m4ln,  puip)). 

(X  !-•  (Atroy  of  r«4li,  /projl.lor/moin,  /projl.fot/mola,  purp)), 

(V  H*  (arroy  of  roali.  /proil.for/ntUn,  /projl.foi/inAtu.  purp)), 

(WX  ^  (4f*4y  of  r«4i«i  /projl.for/maln,  /proll.foiym*ini  purp)), 

(VVV  ^  (btray  of  raaU,  /projl-for/maln,  /pio|i.for/main,  purp^), 

(X//ATN  ^  (array  of  raaU,  /projl. for/mala,  /projl.for/maln,  purp)), 

{XHATOlU  (-•  (array  of  i«aU,  /projl. for/maln,  /piojl.for/maio,  purp)), 

(VX  M  (array  of  raaU,  /projl. for  mala,  /projl.fei/maln,  purp)), 

(VV  ^  (array  of  r«al«,  /projl. for/mala,  /projl-for/maltt,  purp)), 

(Z  ^  (ariay  of  roaU,  /projl.for/maln.  /projl. for/maln.  purp)). 

(XXAT  (array  of  roaU,  /projl  for/maln.  /projl.for/maln,  purp)). 

(ZRAT  (array  of  roaU,  /projl.for/maln,  /projl.for/maln,  purp)), 

(/^U  ^  (array  of  rcaU,  /projl. for/maln,  /projl. for/maln.  purp)), 

(P  (array  of  roaU.  /projl.for/maln.  /projl.for/maln.  purp)). 

(F  ^  (array  of  roaU,  /projl. for/maln,  /projl.for/maln,  purp)}, 

(FT  ^  (array  of  roalr,  /projl.for/maln,  /proil.for/maln,  purp)), 

(H  (array  of  roaJr,  /projl.for/maln.  /projl.for/maln.  purp)). 

(PN  »-•  (array  of  realr,  /projl.for/maln,  /projl.for/maiiii  purp)). 

(TEMPI  (array  of  roaU,  /projl.for/maln,  /projl.for/maln,  tomporary  malrli)), 

(TEMPa  (array  of  roaU,  /projl.for/maln,  /projl.for/maln,  iomporary  malilx)), 

(Q  »-•  (array  of  roalo,  /projl.for/maln,  /projl.for/maln.  purp)}, 

(//  H*  (array  of  roalo,  /projl.for/maln,  /projl.for/maln,  purp)), 

(E  ^  (array  of  rtali,  /projl. (or/maln.  /projl.for/maln,  purp)), 

(HT  urt  (array  of  roalr,  /projl.for/maln,  /projl.for/maln,  purp)), 

(SI  (array  of  roaU,  /projl.for/maln,  /projl. for/maln,  purp)), 

(W  (array  of  rtaU.  /projl.for/maln,  /projl.for/maln,  purp)), 

(WT  (array  of  r«al«,  /projl.for/maln,  /projl.for/maln,  purp)), 

(XTJ LDB  ^  (array  of  roalr,  /projl.for/maln.  /projl.for/maln,  purp)), 

(XTILDBT  (array  of  r«aU,  /projl. for/matn,  /projl-fer/maln,  purp)), 

(BPSILOH  (array  of  roalr,  /projl. for/maln,  /projl. for/ main,  purp)), 

(GropA  (array  of  roaU,  /projl. for/mnin,  /projl.for/maln,  purp)), 

(PI  ^  (array  of  roalo.  /projl. fui/maln,  /projl.for/maln,  purp)), 

(Hatntg  (array  of  cbaraclero,  /prv  11. for/maln.  /projl.for/maln,  purp)} 

)  _  _ 

3.3.2  Design  Recovery  Reaching  the  design  recovery  task,  it  is  time  to  provide  links  between 
the  items  identified  in  the  previous  teisk.  The  first  adjustment  to  the  PROJfJCT-DESIGN  schema 
is  to  give  a  name  to  the  project.  The  nature  library  population  brings  up  another  problem  with 
naming.  It  is  possible  to  refer  to  the  library  as  the  project,  or  to  refer  to  the  final  system  as  the 


project,  or  to  the  individual  modules  as  projects.  Naming  the  modules  as  projects  is  chosen.  The 
present  system  is  detailed  to  the  extent  of  outlining  the  modules  needed  to  make  the  system  fully 
functional.  Initial  additions  to  the  system  are  most  beneficial  in  these  areas.  In  keeping  with  this 
notion,  it  is  reeisonable  to  assume  that,  conversion  of  individual  modules  will  need  to  be  tracked. 
Therefore,  modules  will  be  considered  as  projects  and  given  names.  This  name  will  be  used  to 
track  the  module  and  its  associated  design  products.  Referring  to  company  policies  and  standards 
at  this  point,  a  decision  is  made  about  the  necessary  collection  of  design  documents.  Since  there 
are  no  standards  presently  in  place  for  accomplishing  the  task  at  hand,  design  documents  will  be 
created  as  needed. 

The  first  pass  through  the  program  divides  it  into  three  parts.  The  first  section  initializes 
variables  and  opens/creates  all  of  the  output  files.  Section  two  is  a  loop  that  does  a  number  of 
calculations  based  on  the  number  of  samples  selected.  The  final  section  closes  all  of  the  output 
files.  This  shows  that  all  of  the  work  is  accomplished  in  the  second  portion  of  the  program.  The 
comments  in  the  middle  of  the  program  depict  this  section  as  sequence  of  matrix  operations.  These 
operations  appear  to  be  divided  into  steps  of  four  to  eight  statements.  I'his  is  about  the  best  that 
can  be  gleaned  from  examining  the  code.  This  is  a  textual  description  of  the  program.  It  will  be 
saved  in  an  overview.  The  information  gathered  thus  far  is  enough  to  translate  the  module  into 
the  new  system. 

In  this  task  kalmaii^iltcrhas  been  added  to  the  set  of  reengineering  projects.  The  only  design 
product  presently  available  is  the  textual  description  of  the  module. 

— PROJECT  JJ'ESIGN _ 

project^uame  :  (kAbiuucJUter} 

projeci^inj 0  :  {(kalmui-filter  luJmw-filterJlexl-Dverview)} 


3.3,S  Injormation  Inspection  and  Redesign  Bused  on  the  information  recovered  in  the  pre¬ 
vious  task,  the  plan  developed  here  during  the  information  inspection  is  as  follows. 

1.  Develop  array  objects 

2.  Develop  matrix  objects 

3  Develop  matrix  operations 

4.  Develop  a  shell  with  variable  declarations 
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5.  Incorporate  variable  initialization  witliin  the  shell 

6.  Incorporate  the  second  portion  of  the  module  by  adding  one  collection  of  steps  at  a  time 

7.  Incorporate  file  output 

This  set  of  steps  is  sent  to  the  next  task  in  the  renovation  phase.  The  redesign  task  will  not  be 
used  since  the  objective  of  this  research  is  to  capture  the  original  functionality  of  the  modules. 

3.3.4  Reimplementation  The  result  of  applying  this  task  is  a  new  representation  of  the 
existing  system.  The  actual  application  of  this  task  is  discussed  in  detail  in  the  next  chapter. 

3.4  Summary 

The  schemas  defined  in  this  chapter  can  be  applied  to  any  project  that  desires  to  populate  a 
software  library.  The  chapter  that  follows  discusses  the  use  of  these  schemas  in  an  actual  project. 
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IV.  Implementation 


4.1  Inti'oduction 

As  discussed  in  the  previous  chapter,  a  two-step  approach  was  used  to  solve  the  problem.  Step 
one  used  Byrne’s  model  to  plan  the  project  and  step  two  was  to  implement  the  plan,  Th.s  chapter 
discusses  the  implementation  which  essentially  followed  the  steps  as  outlined  in  the  information 
inspection  task  of  the  last  chapter.  However,  there  was  the  need  to  do  other  preliminary  research. 
Initial  analysis  called  for  a  study  of  APTAS  to  get  an  overall  view  of  the  system  that  needed  its 
library  populated,  Also,  a  survey  of  existing  code  was  conducted  to  select  suitable  modules  for  the 
test.  This  chapter  covens  tne  prelim' ■'.aries  and  then  details  the  renovation. 

4.2  Preliminaries 

A  quick  look  through  the  available  modules  showed  that  FORTRAN  was  the  primary  language 
used.  This  led  to  a  study  of  FORTH-iN  and  its  datatypes.  Following  this  study  was  a  look  at  ClDL 
and  its  data  structures.  The  reason  for  studying  ClDL  was  that  this  is  the  language  used  in  APTAS. 
Also,  it  was  necessary  to  compare  the  data  types  available  in  the  two  languages.  Following  the  study 
of  the  languages,  APTAS  was  surveyed  to  learn  how  it  was  constructed.  Its  primary  components 
consisted  of  a  knowledge  base  and  a  collection  of  library  routines  called  primitives,  The  structure 
of  APTAS  is  represented  in  Apper  dix  A.  The  top  level  presents  a  tracking  system  to  be  developed. 
Questions  are  presented  to  the  user  and  the  answers  determine  what  additional  levels  are  added 
to  the  developing  structure.  Fach  new  level  adds  new  questions  and  each  new  answer  may  add 
new  levels.  This  process  continues  until  there  is  sufficient  detail  for  the  knowledge  base  to  select 
between  system  primitives. 

The  research  started  with  gathering  samples  of  moduies  from  existing  code  that  needed  to 
be  put  into  the  new  system  and  gathering  samples  of  existing  primitives.  Appendix  D  presents  the 
module  that  was  chosen  for  transformation  to  the  new  system.  It  is  a  FORTRAN  implementation 
of  a  kalraan  filter  as  outlined  in  (4).  This  module  was  chosen  because  it  is  used  in  several  locations 
in  the  APTAS  structure.  The  TRACK-DATABASE  presented  in  Appendix  B  is  representative  of 
a  primitive  module  in  the  APT.4S  system.  This  particular  module  was  chosen  to  show  the  wide 
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variety  of  information  that  must  be  represented  and  the  many  files  that  are  used  in  maintaining 
the  system  knowledge  btise. 

After  analyzing  the  samples  and  the  APTAS  structure,  the  approach  to  transform  the  FOR¬ 
TRAN  modulo  v/as  further  divided  cis  follows:  implement  the  filter  in  Cidl  as  a  stand-alone  module; 
insert  the  new  module  into  the  knowledge  base  at  the  top  level;  and  move  the  module  to  its  proper 
place  in  the  hierarchy.  This  approach  was  chosen  for  several  reasons.  The  module  presently  existed 
as  a  stand-alone  module.  So  implementing  it  in  this  manner  first  would  allow  testing  and  verifica¬ 
tion  of  operation  apart  from  the  APTAS  system.  This  would  ensure  the  Cidl  representation  was 
correct  and  would  enhance  understanding  of  Cidl  syntax  and  semantics.  Inserting  the  module  at 
the  top  level  would  allow  easier  integration  testing.  Since  all  of  the  intermediate  modules  are  not  in 
place,  having  this  module  at  the  top  level  will  make  it  much  easier  to  ensure  it  is  invoked.  Moving 
the  module  to  its  final  level  will  not  require  additional  testing  since  integration  and  functionality 
have  been  previously  checked.  It  is  a  matter  of  locating  and  replacing  the  corresponding  module 
name  in  the  hierarchy.  After  t  lese  preliminaries,  research  continued  with  the  steps  outlined  in  the 
previous  chapter. 

4.H  Source  Code  Analysis 

This  phase  started  with  an  examination  of  the  files  that  were  used.  The  source  code  wt^ 
contained  in  a  single  file.  However,  examination  of  the  code  showed  that  16  other  files  were:  created 
during  execution.  Additionally,  the  file  contained  one  subroutine  to  generate  random  numbers  and 
seven  subroutines  for  matrix  operations.  FORTRAN  library  routine  that  were  used  in  the  program 
were  Sin,  Cos,  and  Ran.  All  variables  used  in  the  program  were  single  integers,  one-dimensional 
arrays  of  reals,  or  two-dimensional  arrays  of  reals.  The  relationship  between  the  subroutines  and 
the  main  program  was  that  all  information  exchange  was  accomplished  by  passing  variables  to  the 
subroutines  so  they  could  be  modified. 

As  part  of  the  source  code  analysis  a  search  of  the  APTAS  library  was  performed  to  find 
routines  that  could  be  reused  in  the  new  module.  The  math  module  provided  Sin,  Cos,  and 
Random  functions.  ClDL  did  not  directly  implement  arrays,  however,  there  was  an  existing  array 
module  that  provided  one-dimensional  array  operations  and  a  matrix  module  that  provided  two- 
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dimensional  array  operations.  These  modules  did  not  provide  all  of  the  required  functionality, 
but  they  served  as  good  models  and  were  modified  and  reused.  A  matrixop  module  was  also 
available,  but  it  only  implemented  multiplication  and  transposition.  The  following  list  shows  all  of 
the  functionality  the  modules  were  required  to  provide. 


Math 

Array 

Matrix 

Matrixop 

sin 

assign 

assign 

add 

cos 

index 

index 

subtract 

random 

print 

print 

multiply 

initialize 

initialize 

inverse  (limited  to  2  x  2) 

create 

create 

transpose 

4-4  Design  Recovery 

An  important  part  of  this  step  is  to  choose  a  representation  that  allows  easy  transition  into 
the  new  system  and  representation  of  all  the  recovered  information.  Since  the  new  system  language 
is  CiDL  it  was  also  chosen  to  represent  the  recovered  design  and  facilitate  translation  into  the  new 
system.  The  design  representation  of  the  existing  system  was  not  very  complex.  Its  structure  can 
be  described  as  follows. 


declare  variables 
open  files 
initialize  variables 
loop 

do  filter  calculations 
update  variables 
write  values  to  files 
end  loop 
close  files 


The  variable  initializations  were  sequences  of  f'ORTRAN  statements.  The  filter  calculations  were 
sequencer  of  statements  along  with  calls  to  subroutines  and  library  functions.  A  suitable  ClDL 
stru'-ture  to  represent  the  program  turned  out  to  be  the  le*  statement.  Its  structure  is  given  here. 
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let 


declare  variables 


in 

open  files 
initialize  variables 
loop 

do  filter  calculations 
update  variables 
write  values  to  files 
end  loop 
close  files 

end  let 

Here  also  the  program  would  consist  of  a  sequence  of  statements,  procedure  calls,  and  library 
function  calls. 

1^.5  Information  Inspection 

The  plan  developed  in  this  phase  to  do  the  actual  transformation  was  straight  forward.  It 
would  be  a  phased  conversion  beginning  with  the  declaration  of  variables  in  the  new  implementation. 
The  next  phase  would  be  implementation  of  the  initializations.  Once  these  had  been  carried  out, 
the  sequence  would  continue  with  implementing  statements,  then  library  function  calls,  procedure 
calls,  and  finally  file  output.  Once  file  output  was  complete,  comparisons  between  the  original 
functionality  and  the  new  implementation  would  begin.  This  would  mark  the  end  of  converting  the 
selected  module  to  ClDL. 

The  next  phase  of  the  conversion,  as  discussed  previously,  would  be  to  put  the  new  module 
in  the  knowledge  base  at  the  top  level  so  the  interfacing  could  be  worked  out.  This  too  would  need 
to  be  a  phased  task.  Beginning  at  the  top  level,  it  would  be  necessary  to  insert  a  new  menu  option 
to  allow  testing  of  a  development  module.  This  involved  creating  the  option,  setting  necessary 
variables  to  deactivate  the  defaults,  and  activating  levels  that  implemented  the  new  functionality. 
Also,  the  structure  of  the  knowledge  base  makes  it  essential  that  the  new  module  be  represented 
in  the  following  files. 

global.desc  describing  the  new  type  and  its  parameters 
global.gsdl-t  describing  the  graphical  representation  of  the  new  type 
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global.gsdUl  describing  the  displayable  components 
global.synth  as  a  template  for  generating  ClDL 
global.form  representing  the  user  interface 

These  items  would  be  developed  at  this  point  in  the  transformation.  After  this  interfacing  is 
completed,  testing  is  performed  to  ensure  proper  operation  of  the  new  module  and  its-ir*eraction 
with  the  knowledge  base.  The  last  phase  would  simply  require  renaming  the  module  level  as 
dictated  by  the  APTAS  structure.  This  would  remove  the  module  from  the  test  status  and  position 
it  as  a  normal  primitive.  Following  this  plan,  the  actual  redesign  can  begin. 

4  <6  Redesign 

The  initial  decision  sequence  did  not  require  use  of  the  redesign  task  in  system  renovation. 
Since  the  modules  were  being  used  in  other  programs  where  they  were  assumed  to  function  correctly, 
the  idea  was  to  duplicate  this  functionality  without  redesign.  During  the  actual  reimplementation, 
however,  it  became  necessary  to  readdress  this  decision.  As  discussed  in  (8),  the  relationship 
between  this  task  and  the  next  is  iterative.  This  proved  to  be  the  case  in  this  project.  Two 
particular  problems  are  discussed  here. 

The  transcendental  functions  used  from  the  FORTRAN  library  were  passed  degrees  for  the 
calculation.  Passing  these  same  numbers  to  the  ClUL  functions  resulted  in  errors  of  several  orders 
of  magnitude.  This  was  not  discovered  until  the  file  output  was  implemented.  To  correct  this  error 
required  a  change  in  the  baric  design  to  convert  these  numbers  to  radians  as  required  by  the  ClDL 
library. 

The  matrix  inverse  subroutine  in  the  original  module  was  implemented  using  the  goto  state¬ 
ment  available  in  FORTRAN.  Since  ClDL  did  not  have  a  similar  statement,  this  procedure  had 
to  be  completely  redesigned.  Since  this  version  of  the  filter  inverts  only  2x2  matrices,  a  limited 
procedure  was  easily  developed.  Extending  this  procedure  to  accommodate  3x3  matrices  is  not 
very  hard.  However,  extending  the  matrix  inverse  operation  for  a  general  nxn  matrix  will  reqiiire 
going  to  a  block  structured  implementation  of  an  algorithm  such  as  the  Gauss- Jordan  elimination 
method  (14). 
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Jf.l  Reimplementation 

The  reimplementation  followed  the  plan  developed  in  the  information  inspection  task.  Varia¬ 
tions  in  the  plan  were  due  to  discoveries  during  the  implementation.  Two  of  the  problems  encoun¬ 
tered  were  discussed  in  the  redesign  task  since  they  required  a  new  look  at  the  original  redesign 
decision.  Other  issues  that  did  not  have  such  a  large  impact  are  discussed  here  as  the  reimplemen¬ 
tation  is  outlined. 

Declaring  integer  and  real  variables  turned  out  to  be  straight  forward.  Declaring  and  ini¬ 
tializing  arrays  required  modifying  the  available  modules  as  described  previously  to  provide  the 
needed  functionality.  Once  the  array  modules  were  In  place  and  tested,  declaring  and  initializing 
arrays  was  easily  accomplished.  The  matrix  module  built  upon  the  array  module  and  led  to  further 
modifications.  Finally,  the  matrixop  module  was  developed  and  tested. 

As  the  statements  wore  being  converted,  several  undeclared  variables  were  found  and  had  to 
be  decla'ed.  FORTRAN  allows  some  variables  to  be  declared  at  use  time  and  this  is  not  allowed 
in  CiDL.  Another  problem  that  developed  was  with  the  names  chosen  for  the  variables  in  the 
original  program.  They  turned  out  to  be  reserved  words  in  CiDL  and  had  to  be  renamed.  Some  of 
the  original  variable  types  had  to  changed  later  also  since  CiDL  had  much  stronger  type  checking 
(integer  to  real).  Translation  proceeded  by  taking  FORTRAN  statements  and  mapping  them  to 
statements  in  CiDL.  There  was  continuou.s  testing  to  ensure  functionality  was  retained. 

To  complete  the  CiDL  implementation  of  the  module,  a  complementary  test  had  to  be  devel¬ 
oped.  The  fi  iJil  numbers  produced  by  the  CiDL  implementation  were  not  close  enough  to  the  figures 
produced  by  the  original  program  to  verify  functionality.  It  was  suspected  that  the  differences  were 
due  to  the  random  number  generator  differences.  FORTRAN  allowed  setting  the  seed  of  the  gen¬ 
erator  and  CiDL  did  not.  A  test  was  developed  by  replacing  the  CiDL  random  number  generator 
with  the  sequence  of  numbers  produced  by  the  FORTRAN  program.  Using  these  numbers,  the  two 
programs  had  identical  output.  This  marked  the  end  of  converting  the  chosen  FORTRAN  modulo 
to  a  stand-alone  module  in  CiDL.  Reimplementation  moved  to  the  task  of  integrating  the  module 
into  the  knowledge  base. 
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4-8  Summary 

APTAS  presently  contains  the  overall  structure  for  tracking  systems,  however,  Appendix  B 
lists  the  modules  that  are  presently  still  required  to  completely  implement  the  system.  Addition  of 
these  modules  will  not  require  changing  the  tructure  of  the  present  system.  The  method  outlined 
in  this  and  the  previous  chapter  can  be  used  to  put  additional  modules  in  the  knowledge  base. 
Adding  additional  capability  will  modify  the  structure  and  will  require  more  changes.  The  biggest 
decision  to  be  made  will  be  determining  the  proper  location  in  the  existing  hierarchy. 


I 
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V.  Conclusion  and  Recommendations 


5. 1  Conclusion 

Using  design  recovery  as  a  means  to  populate  a  software  librarj^  is  feasible  especially  in  the 
case  where  the  structure  of  the  library  is  in  place.  This  allows  the  focus  to  be  on  obtaining  modules 
with  specific  functionality.  Even  if  the  modules  cannot  be  used  as  is,  they  can  provide  guidance 
for  developing  new  modules  during  the  redesign  task  of  the  renovation  phase. 

The  decision  to  skip  the  redesign  step  proved  unwise.  The  model  showed  that  the  redesign 
and  reimplementation  steps  were  iterative  in  nature.  Once  reimplementation  started,  problems 
were  encountered  that  required  the  redesign  step. 

The  original  problem  statement  in  Section  1.3  outlined  the  four  areas  that  needed  to  be  studied 
in  order  to  accomplish  the  library  population.  The  internal  formats  of  the  APTAS  knowledge  base 
are  presented  in  Appendix  A.  Characterizing  the  modules  that  need  to  be  placed  into  the  library 
must  be  accomplished  for  each  module.  Following  the  procedures  in  Sections  3.2.2  and  3.2.3  will 
capture  the  module  behavior.  A  sample  plan  for  mapping  the  recovered  design  into  the  new  format 
is  presented  in  Section  3.3.3.  This  plan  must  be  customized  for  each  new  module. 

5.2  Recommendations 

The  recommendations  presented  here  are  divided  into  areas  that  need  to  be  addressed  in  r 
detail.  The  ordering  of  the  recommendations  is  arbitrary. 

5.2.1  The  Knowledge  Base  The  files  that  make  up  the  knowledge  base  have  grammars 
associated  with  each  of  them.  They  are  also  common  to  all  users  of  the  system.  Presently  there 
are  no  tools  specifically  designed  to  raaintjun  these  files.  Corruption  of  these  files  will  lead  to 
system  wide  problems.  Two  suggestions  for  helping  with  this  problem  are  developing  a  forms  based 
interface  for  the  files  and  developing  a  smaU,  stand-alone  testbed  for  new  modules.  The  interface 
could  be  made  to  maintain  the  grammar  for  the  global. defjc,  global.form,  and  other  files  in  the 
knowledge  base  limiting  the  possibility  of  corrupting  these  files. 

The  APTAS  Software  User’s  Manual  (13)  also  contains  a  communication  network  model  cis 
another  example  of  executable  specification.  It  is  a  much  smaller  system,  but  it  uses  all  of  the 
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knowledge  base  component  types  used  in  the  APTAS  system.  A  similar  model  would  make  an 
excellent  testbed  for  new  modules  for  the  APTAS  system.  This  would  allow  easier  testing  and 
integration  into  the  knowledge  base. 

The  items  described  would  aid  modifications  to  the  system  as  it  is  presently  defined.  If  the 
structure  needs  to  be  changed,  additional  considerations  may  be  necessary. 

5.5.2  Selecting  Modules  The  primitives  used  in  the  APTAS  system  can  best  be  described 
as  communicating  sequential  processes  as  defined  In  (11).  They  do  their  processing  on  information 
sent  by  other  processes.  After  the  computation,  results  are  sent  back  to  the  calling  process.  This 
description  hints  at  the  best  type  of  modules  to  select  for  the  knowledge  base.  Besf  here  refers  to 
structure.  Modules  that  have  all  of  their  functionality  hidden  within  a  procedure  are  ideal.  All 
access  to  the  internal  structures  should  be  through  procedure  calls,  and  the  procedures  must  be 
able  to  retain  their  values  across  calls.  For  modules  that  do  not  fit  this  structure,  additional  work 
is  required  to  decide  which  parts  of  the  module  are  implementing  the  required  behavior  and  which 
parts  are  not  needed.  The  worst  type  modules  would  be  those  that  perform  interwoven,  dissimilar 
operations. 

This  idea  is  also  beneficial  in  the  development  of  candidate  modules  for  other  systems.  Fol¬ 
lowing  the  structure  outlined  above  would  allow  oasier  reuse  of  the  module  in  the  APTAS  system. 
It  sill  also  promote  easier  maintenance  on  the  target  system. 

5.2.3  Translating  Modules  Due  to  the  large  number  of  files  required  to  complete  the  system 
knowledge  base,  automation  of  the  process  se^ms  to  be  a  must.  One  problem  that  may  face 
automating  the  process  will  be  the  number  of  language's  used  in  candidate  modules.  Each  language 
will  require  developing  a  translator.  If  there  are  many  modules  in  a  given  language,  this  may  be 
beneficial.  Since  the  primitives  that  are  required  may  heve  small  sizes,  it  may  be  easier  to  code  in 
ClDl.  using  the  selected  modules  as  guides  than  to  make  translators  to  convert  to  Cidl. 
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Appendix  A.  Module  Characteristics 


Populating  the  knowledge  base  of  the  APTAS  system  requires  manipulating  six  files.  Five  of 
the  files  contain  a  portion  of  the  information  characterizing  the  description  of  a  module.  The  final 
file  is  the  actual  ClDL  implementation  of  the  functionality  of  the  module.  This  appendix  presents 
the  TRACK-DATABASE  module  as  it  appears  in  the  five  files  that  describe  the  module.  It  also 
describes  the  purpose  of  the  file  and  the  information  it  contains. 

A.l  Description 

The  description  of  the  TRACK-DATABASE  is  given  in  the  global.desc  file.  It  acts  as  the  help 
file  for  the  user  of  the  system.  It  is  accessed  from  the  describe_type  function  of  the  GDE  editor. 
This  file  describes  the  types  that  are  available  to  the  system  and  lists  all  the  parameters  that  arc 
contained  in  an  instantiation  of  a  particular  type  along  with  their  function,  and  the  interface. 


mCK.DATABASEi 

This  Hodula  ii  ratponalbl*  lor  th«  itoraga, 
■anagoBont  and  r«trt«val  ol  all  track  data. 
PARAHETERS  TD  SPECIFY! 

PUYFORN  i  platloratypa 
(ground  or  airboma) 
TRACK_BUFFER_SIZE  :  int 
(ranga  :  1  to  60) 
TRACK_HISTORY_SIZE  !  int 
(ranga  :  2  to  20) 
PLATFORR_POS_BUFFER_SIZE  :  int 
(range  :  2  to  20) 
MIS3I0B.SUFFER.3IZE  :  int 
(ranga  :  1  to  10) 
REqUIREO.APPLICATIOlJtENORY  :  int 
(Thia  paraaater  value  ia 
calculated  during  aynthaala. 

A  value  given  to  it  in  the 
graphical  editor  vill  be 
overaritten  by  the  eyntheeia 
engine.  It's  visibility  in 
the  graphical  editor  is  nerely 
to  provide  inlonation  alter 
ayntheelB.) 

RAM.MEMORY  ;  int 

(hoe  such  is  available  lor 
the  track  database) 

« 
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A. 2  ICON  Represenlniion 


This  portion  of  the  TRACK-DATABASE  is  taken  from  the  global.gsdl-t  file.  It  describes  how 
objects  are  to  be  represented  graphically  and  how  they  should  be  positioned  in  the  GDE  editor. 
Also  shown  is  the  information  for  a  relation. 


TABLE  TRACKER.DOMAIN 
MODULE  :  TYPE 

TRACK.DATABASE  ->  ICON  -  HED.BLUE.RECT 
LABEL  -  TOP  BOTH 
DEFAULT.POSITIOIt  -  CEHTER 
CONTENTS  • 

MODULE  ->  ICON  -  SH.IIKCT 
->  LABEL  -  CENTER  NAME 
DEFAULT.POSITION  -  CENTER 
IN.PORT  ->  ICON  -  MINI.CIRCLE 
LABEL  -  LEFT  NAME 
DEFAULT.POSITION  -  LEFT 
OOT_PORT  ->  ICON  -  MINI.CIRCLE 
LABEL  -  RIGHT  NAME 
DEFAULT.POSITION  -  RIGHT 
OISPUY  REUTIONS: 


ASYNC  i  RELATION 
WIDTH  «  0 
COLOR  -  "Maganta" 

FROM.END  -  PLAIN 
TO.END  »  ARROW 

VALIO.PAIRS  -  (MODULE, MODULE) 
EXTRA. AKO; 


END 
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A. 3  Components 


The  global .gsdl-l  file  describes  displayable  components  of  a  particular  module.  !t  is  accessed 
by  the  GDE  editor. 


TifUCXER.DOMAlN 

TRACX.D&TABASE  :  MODULE  - 
DECLARE 

FUTFURN  :  PLATFORMTYPE; 
TRACK.BUFFER.SIZE  :  INT; 
TRACK.HISTORY.SIZE  :  INTi 
PLATFORM_POS.DUFFER.SIZE  :  IMl'i 
KISSIOM.BUFFER.SIZE  :  IKT; 
REqUIR£D.APPLICAT10N_HENQRY  :  INT; 
IL'JI.HEMDRY  ;  INT 
END 


A. 4  Synthesis 

In  the  global.synth  file  all  of  the  modules  arc  represented  as  ClDL  templates  identifying 
parameters  of  the  module  type.  This  information  is  used  by  the  synthesis  engine,  to  generate 
ClOL. 


(d«lT«r  *priji~aoduI«i)*  nil) 

(••tq  *priB-'Bodul«t* 

>(  <-CDL  (<-PA  (platlorn) 

(typaunion  ( (typaanvwllt  $ground) 

(typaanunll't  Salrborne))) 

(axpvold)) 


(-PA  (track.bufier.aize) 

Int 

(azpvoid)) 

(-PA  (track.hlatozy.aiza) 

Int 

(axpvoid)) 

(-PA  (platfoni_po«_buflar.aiz8) 

int 

(expToid)) 

(-PA  (alealon.bulfar.olza) 

Int 

(azpvoid)) 

(-PA  (kaquiirad.application.iiaaory) 

int 

(azpvoid)) 

(-PA  (ran.naaory) 

int 

(azpvoid)) 

) 

0 

(DECLPARAM  TRACX,DATABASE_ CREATE 

0 

TRACK.DATABASE  (EXPSTRUCT  NIL))) 


)) 
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A. 5  Selection 


The  most  important  file  to  be  modified  is  global.form.  It  contains  form  information  that  is 
presented  to  the  system  user  and  module  selection  criteria.  The  form  contains  the  questions  tliat 
guide  the  user  through  the  refinement  of  the  system.  Based  on  user  input,  dilferent  combinations 
of  modtiles  are  combined.  Updating  this  file  requires  locating  a  position  in  the  hierarcliy  for  the 
module  and  developing  the  selection  criteria. 


LEVELS 

/TRACKINQ 

"Tracker  Boundary  Conditiona"  TRUE 

NOT.DEFAULT  EQ  NOHSEMSE  1  HQT.DEFAULT  NE  "true"  "Default  Tracker?" 

STACK 

"true"  VARIABLE_3ET(DEFAULr .TRACKER,  "true") 

ACTIVATE_LEVEL(/TRACKI«0/DEF AULT, .TRACKER) 
ACTIVATE_LEVEL(/TRACKIIIO/DEFAULT.TRACXER/TRACK_DATABASE) 
ACTIVATE_LEVEL  (/TRACKIMG/DEFAULT.TRACKER/SCAII.TO.TRACK.CORRELATIDR) 
ACTIVATE.LEVEL  (/TRACKUia/DEFAULT.TRACKER/PRE3EIITATI0II.PR0CESS) 

"falee"  VARIABLE_SET(DEFAULT.TRACKER,  "ialee") 

DEACTIVATE.LEVEL(/TRACKIMO/DEFAULT.TRACKER) 
DEACTIVATE.LEVEL(/TRACKUIO/DEFAULT.TRACKER/TRACK.DATABASE) 
DEACTIVATE.LEVEL  (/TRACKUIO/DEFAULT.TRACKER/SCAN.TO.TRACK.CCRRELATIOll) 
DEACTIVATE.LEVEL  (/TRACKmc/DEFAULT.TRACKER/PRESEIITATIOM.PROCESS) 


"Teat  Iteration*  Count" 

NUMERIC  [1.  100] 

[I,  100]  SAVE_VALUE(TE3T.1TERATIDNS) 
30; 


/TRACKIHQ/DEFAULT.TRACKER 
"Default  Tracker  Top-Level"  FALSE 

"No  questions,  this  is  a  default  nodule." 
CHECKLIST  "" 

END; 

/TRACKIMC/DEFAULT.TRACKER/TRACK.DATABASE 
"Default  Tracker  Database"  FALSE 

"No  questions,  this  is  a  default  eodule." 
CHECKLIST  "" 

END 
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modules 


"TIUCKER^EIIVIROIIMENT" 

"Sunsor.Data."  "SENSOR.HODEL" 

{"ITERATIONS"  ■  TEST.ITERATIQNS; 
"PERTUBBATION.FACTOR"  -  0.02; 

"TARGET.SPECS"  -  *"t[COMPUTE.FUN  -  ‘DEPAULT.EQl  ; 

AROS  -  £0.0B9i  0.009;  1.78; 

1.16;  92.31;  8.23]]; 
[CQMPUTE.FUN  -  ‘DEFAlJLT_EIJ2  ; 
ARCS  -  [0.191;  0.083;  2.46; 

2.09;  81.01:  -7.23]]]": 

"SENSOR"  -  *"*SENSOR.TYPE"} 
d«l«ult_tr«ck«r  EQ  "t.7U«" 

"Trackar"  "TARQET.TRACKER" 

dafault^trackar  N£  "true" 

"Trackor"  "NEW.TRACKER" 

"Output"  "OUTPUT.DISPLAY" 

{"TABLE.DATA.FIU;"  - 

"dat«_llla«/d«Iault_track«r_tabla_data.txt"; 
"MAP,DATA_FILE"  - 

"data.l ilaa/dalault.trackar.aap.data . tzt " ; 
"ITERATIONS"  -  TEST.ITERATJ0N3} 

REL  ( "Sen8or.Scaii_!''r»«a_To_Trackar" ,  "Aaync" , 

"Sanaor .Data . acua.lraaa.out" .  "Trackar . ocau.lraat. In" • 
*"08naricScanFra.aa"} 

HEL("Oparator_Quary_to.Trarkttr" ,  "Aayac" , 

"Output . quary.out " ,  "Trackar .uaar.qutry. in" , 
‘"OanaricOuax-y") 

REL ( "Trackar .Data.to.Diaplay" ,  "Aayac" . 

"Trackar .diaplay.data.out",  "Output .reply. in" , 

* "OanaricTrackData") 
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"TAROET.TRACKER" 

"TDB"  "TRACK.DATABASE” 

{"IUM.MEMQRY"  -  RAM.MEHORY; 
"REQUIRED_APPLICATIOM.KeMQRY"  -  0; 
"MISSI01I.BUFFER.SIZE"  -  6; 

"PUTF0RM_P0S.BUFFER.SI2E"  -  8; 

"TRACK.H1ST0RY.S12E"  ■  10; 

"TRACK_BUFFER.SIZE"  -  MUM.OF.TARGETS ; 

"PLATFORM"  -  “""FUTFORM.TYPE"} 

"STC"  “SCAB.TO.TRACK.CDRRELATION" 

<"TEIlMIllATED_TEHT_TftACK.SAVE..LIMT"  -  Bj 
"TERMIIIATED.REQ.TRACK.SAVE.LIMIT"  -  20  j 
"TEltTATIVE_Ta.REaUUR.THBE3H0LD"  -  4; 
"TERMIKATIOM.THRESHOLDS"  -  ""[4:  2]"; 
"IIIITIAL.aATE.DELTAS"  -  ’"[6.0;  B.O]“j 
"REDUCED.DELTA.FACTORS"  -  *“[0.8;  0.8]"; 
"IMCREASED.DELTA.FACrORS"  -  “"[2.0;  2.0]"; 

"DECOYS"  -  '"FALSE"; 

"FALSE_AURM_PROfiABlLITY"  -  0.10; 

"TAROET.TRAJECTORY"  -  ""MAMEUVERIIIO"; 
"TARQET.OEMSITY"  '"MEDIUM"; 
"TAROET_PRODABILITY.OF_DETECTIO«"  -  0,9; 

"Pr.ATKORM"  ■  *"”PLATFOBM_TYPE"; 

"DATABASE"  -  •'"TDB"} 


"PP"  "PRESEHTATI0N.PR0CES3" 

{"DATABASE"  ■  '"TDB") 

DECL<"Sc«ii_KrtM.In"j  "In.Port",  "") 

DECL("U«er.Qu«ry.In",  “In.Port", 

DECL("Di8pl«y_D«t«_0ut",  "Out.Port",  "") 

RELC'STC.DatnbMO.TDB.PnrwMitor.MoUul*",  "PwMoter.Hodul*", 
"STC.databan*",  "TDB",  "“) 

R£L("PF_Databasa.T0D_Pai4aMt«r.Nodul«",  "pBrcuiotor.Hodule" , 
"PP.databaia",  "TDB", 

REL("ProceB*_Scan_Fr«M«_In" ,  "Apply .Function" , 

"Scan.Frano.In" ,  "8TC.Proc«*B_3c«n_FraM*" ,  "OenoricScanFmae") 
REL("Proc«BB_UB«r_Quory_In" ,  "Apply .Function" , 

"Uoflr.Query.In" ,  "PP.Qot.Data.For.DiBplay",  "GenericQusry") 
RKL("Forward_Dl8play_0at«",  "For«ard_Function_Result" , 

"PP . Got.Data.For.Diaplay" ,  "Diaplay.Dota.Out " , 

"Ounor IcTrackData" ) 
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Appendix  B.  System  Structure  and  Population 


This  appendix  shows  the  structure  of  the  global.form  file  as  it  represents  the  structure  of  the 
system.  Structure  is  represented  similar  to  a  file  system  directory.  /TRACKING  is  the  top  level  of 
the  structure.  Anything  represented  as  /TRACKING/SOMENAME  would  be  at  the  second  level  of 
the  structure  and  /TRACKING/SOMENAME/OTHERNAME  is  at  the  third  level.  The  LEVELS 
section  of  this  file  represents  the  hierarchy  of  enabling  forms,  and  the  MODULES  section  captures 
the  parameters  and  values.  At  the  bottom  of  the  MODULES  section  are  the  lowest  level  primitives. 
The  primitives  without  parameters,  marked  by  have  not  presently  been  implemented. 


LEVELS 

/TIUCKlIia 

/TRACKINU/ZERO.SCAN.SIONAL.PROCESSmO.IllTEIUGTIOV 

/TRACK:i:ifO/N_SCA!I.AEED_3iaHAI..PRaC£3SIUa.Iirr£IUCTION 

/TRaC1{INO/(I_3CA1I_TEKPUTE_SIOIIAL.PROCE33IKO..IHTERACTION 

/TRACKTN0/M1C[;0UAVE.RADAR_3ENS0R 

/VRACKIHa/X_BAI(0_KED_PRF.RA0AR_SENS0R 

/TRACKINO/PUTPORN 

/TRAUKIMO/PROCESSOR 

/TRACKIlia/DEFAULT.TRACKER 

/TRACKIHa/DEFAULT.TRACKER/TRACK.DATABASE 

/TRACKI»a/DEt'AHLT.TRACKER/3CAl(.T0.TIUa.C0RRELATJ.01l 

/TRACKllia/3EFAULT_TRACKER/PRESEKTATI0«.PR0CESS 

/IRACKmO/CLUTTER 

/TRArKIlia/CLVrTER/EST_PRED 

/TRACKHIO/CHnTER/EST_PRED/DYN_Ml)U/ViiL.PLUS_ACC 

/rRACKIHG/CLViTTER/ASSOC 

/TRACKIll0/CLUTra:R/A!i!U){;/HYP_SELECr_0_SCAH.LTIC00RD 

/TRACKIHO/CLUTTER/AS.Sllc;/!IYP_3ELECT_O_SCAN_C00HD 

/TRACKI«a/CLOTTCR/ASSOC/HYP_SELECT_H_3CAN.UllCOOBJ) 

/TRACMHa/CLUTlF.R/ASSOC/HYP.SELECT.H.SCAN.COORD 

/TRACKIllG/CUnTER/PRO.DEM 

/TRACKINO/SEUSOR 

/TRACKING/SEIISOR/NOISE 

/TRACKIHG/SENSOR/HOISE/DC.CLUTTCR 

/TRACKIlIQ/SEKSaR/IIOISE/PG.CLUTTER 

/TRACKIHQ/SEKSOR/MOISE/DA.CLUTTER 

/TRACKIHa/SENSOR./HUi:SE/PA_CLUTTER 

/TRACKINO/SENSOR/VOISE/SEA 

/TRAC.KING/SENSQR/NOIS£/JAf«INQ 

/TRACKING/SIHQLE.CSO 

/TRACKillO/SIHGLE.CSO/TARCET.CHARS 
/TRACKlHG/3IltGLE_CS0/E3T_PRi  D 

/TRACKIHG/SIN0UJ.C30/EST_PRED/DYK_M0l/.'VEL.PLUS_ACC 

/TRACKIHG/SIN0LE_CS0/ASS0C 

/TRACKIll0/SIIiaLE_CS0/ASS0C/HYP_3ELECT_O_3CAII.UIIC00RD 

/TRACKIIIO/3IHOLE_C30/AS3QC/HYP_3ELECT_0_3CAH.Ct)0RD 
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/TRACKIMO/SIVOLE_CSO/ASSOC/HY?.3ELECT_JI.SCAll_iniCOORD 

/TRACKIHO/SIKOLE.CSO/ASSOC/HYP^SELECT.M.SCAN.CCORD 

/TRACKIHO/SIKOLE.CSO/PKO_Dai 

/TRACKING/GROUPS 

/TRACKIMG/OROUPS/EST.PRED 

/TRACKIHQ/aROUPS/ECT_PRED/DYN.MQD/V£X_PLUS.ACC 
/TRACKING/GROUPS/ ASSOC 

/TRACKIII0/GR0UPS/ASS0C/HYP.SELECT_0_SCA1I_UMCQQRD 

/TRACXING/OROUPS/ASSaC/HYP.SELECT.O.SCAN.COORO 

/TRACKINO/OROUPS/ASSOC/HYP>SE1£CT_K_SCAH_OTICOORD 

/TRACXING/GROUPS/ASSQC/HYF.SELECT.N.SCAII.COQRO 

/TRACXING/GROUPS/PRO.DEN 

/TRACKING/F0RNATI0N3 

/TRACXIS0/F0RHATI0H3/EST.PKEB 

/TRACKIHO/FOIlMATIOHS/EST.PREDyDYX_MOD/VEL.PLUS_ACC 

/'mACKING/FCRMATlONS/ASSOC 

/TIUCXma/FORHATIUHS/PRO.DEM 


MODULES 

"TRACKER.ENVIR01INE1IT" 

"Sansor.Oata" 

"SENSOR.MODEL" 

"Tracker" 

"TARGET.TRACKER" 

"Tracker" 

"MEW.TRACKER" 

"Output" 

"OUTPUT.DISPUY" 

"TARQET.TRACXER" 

"TDB" 

"TRACX .DATABASE" 

"STC" 

"SCAK.TO.TRACX.caRRELATION" 

lippM 

"PRESEMTATION.PKOCESS" 

"MEW.TRACXER" 

"Slgnal.Proceeelng" 

"ZERO_SCAX_SIO_PROC" 

"H_SCAH_REED.SIO.PROC" 

"H_SCAH_TEKPUTE.MATCHIHO_SIO.PRDC" 

"Proceee.Single.Objocte" 

"SINOLE.OflJECTS" 

"Procoas.Siiigla.Objecta.asid.CSUs" 

"SIHOU.OBJECTS" 

"Process.Oroups" 

"GROUPS" 

"Proceee.Foreationa" 

"FORMATIOHS" 

"Proceee.Clutter" 

"CLUTTER.DISCRETES" 

"8IHQLE.0BJECTS" 
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"Eatuiatioii.Prediction" 

"SJOGLE.ESTIHATIOM.PREDICTIOK" 

"ABsociation" 

"SINGLE.AbSOCIATIOH" 

"Pr  oao't  inii_D«aot  ion" 

"SI1IGLE_PR0I10TIQII  .DEMOTION" 

" SIHGLE^ESTIMATION.PREDICTIOM “ 

" Dynaaical.Modal " 

"COHSTAHT.VELOCITY.DYHAMICAL_MODEL" 
"CONSTAHT_ACC£LERATIQN.DYNAHICAL_KOD£L" 
"SINGLE. VEL_PLUS_ACC_DYNAKICAL.MODEL" 
"HoaBuraaent.Model" 

"RAE_MEAS.HODEL" 

"VAE.iP.AS_MODEL" 

"RVAE_MEA3.M0DEL" 

•'Plant_Hoi8e.Mod«l" 

"FIXED.PLANT_NOISE_MODEL" 

"KNONN.AMI.PUHT.NOISEJIODEL" 

"Filter" 

"SIHPLIFIED.GAIBS.FILTER" 

"LEAST.SQUARES.FILTER" 

"KALMAN.FILTER" 

"Iuitial.State_Model" 

"SINGLE_OBS.DERIVED.INIT_STATE.MODEL" 

"SIHGLE.GKP.TRK_DERIVEO_INIT_STATE_HGDEL" 

"SINGLE.  VEL.PLUS.ACC.DYNA1UCALJI0DEL" 
"Modal.Oeneration" 

"GATE_BASEO.NODEL.GEM£RATION" 

"CHI.SQUA«E_BASED.MODEL_OEKERATIOH" 

"LIKELIHOOD.GASED.NOOEL.OENERATiaN" 

"PROBABILITY_BASED.MODEL.OEHF.RATIOH" 

"Nodel.Score" 

"HIT.MISS_PATTERN.SCORINa" 

"CHI.SQUARE.SCORIHO" 

"LIKELIHOOD.3CORINO" 

"PROBABILITY_SCORING" 

"Nodel.Selection" 

"ZERO.SCAN.DYNANICAL.HOOEL.SELECTION" 

"N_SCAN.DYNAMICAL.MODEL.SELECTIOM" 

" Mode 1 .Trans it ion " 

"VEL.TO.ACC.DYHAMICAL.MODEL.TRANSITION" 

"ACC.TO.VEL.DYNAMICAL.HODEL.TRAKSITIOM" 

"SINGLE.ASSOCIATION" 

"Gata.Calculation" 

"RECTANGULAR.GATE.CALCGLATION" 

"EI.LIPTICAL_OATE.CALCUUTIOH" 

"PARALLELOGRAM.GATE.CALCUUTIOH" 

"Candidate.Qenrxation'' 

"GATE_BASED_CAHD1DATE_ueHEPaTI0B" 

"CHI_SqUAHE_BASED.CAl'DISATE.OEKERATION" 

"LIKELIKU0D_BA3ED.CAHDIDATE_GE«ERATI0N" 

"PROBABILITY.BASED.CAHDIDATE.GENERATION" 
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"CBjididate.Scoring" 

"HIT.MISS_PATTERH_SC0RI1I0" 

"CHI.SQUABE.SCORIHO" 

"LIKELIHOOD.SCORING" 

"PROBABILITY.SCORIJIG" 

" Candldate.Select Ion" 

"Z.SCAK.UNCOORD.HARD.SELECTIOH" 
"PDA.HYP.SELECTIOll" 
"GREEDy.HVP.SELECTIOM" 
"MUHKRF.S.HyP_SELECTIOK" 
“MUNKRES.W.CLEASUP.HYP.SELECTIQH" 
"CLEAMUP.HyP.SELECTIOH " 
"AUCTIOa.HyP.SELECTlOM" 
"METWORK.FLOW.HYP.SELEOTIOM" 
IHT.PROG_HyP_SELECTIOH" 
"JPDA.HYP.SELECTION" 
"SPLITTHIG.HYP.SELECTIOH" 
'‘SPLlTTING.W_MERGII(G_HYP_SELECnQH" 
"SIHGUE.M.SCAM.CQORDIMATED.SELECTIOB" 
“SIMGLE.H.SCAH.COORDIMATED.SELECTIOH" 

"SMGLE^lt.aCAll.CQORDIMATED.SELECTION" 
"Hypothoala  Generation" 

"K_BEST.HyP.GEIIERATIO«" 
•■ALL_AB0VE.THRESH0LD_HYP_GE1IERATID1I" 
"Hypotheeis  Selection" 

"M.SCAM.COORD.Kyr-.SELECTIOH" 

"SIMaLE.PROMOTION,DEMOTIOH" 

"Initiation" 

"aM.ALL.INIT.LOGIC" 

"OATE_BASED.IIiIT_LCGIC" 

"CHI.sqUARE_BASED.IHIT.LOaiC" 

"I.IRELIHaOD.BASED_IHIT_LOGIC" 

"PROBABILITy_BASED.IHIT.L(WIC" 

"Track.Scoring" 

"HIT.MISS_PAWERS_SCORIMG" 

" CHI.SgUARE.SCORIHG " 
"LIKELIHOOD.SCORIMG" 
"PROBABILITy.SCORIKO" 

"Pronote.Logic" 

"M_OF_V.PROMOTE_LOQIC" 

"CHI,SQUARE.TEST_PBOMOTE.LOaiC’' 

"LIKELIHOOD.TEST.PBOMOTE.LOGIC" 

"PROBABILITy_n:ST.PIU)MOTE.LOOIv;" 

"Denote.Logic" 

"K_MISS_DEM0TE_L00IC“ 

"CHI.SqUARE_TE3T.DEM0TE_L0GIC" 

"LIKELIHOOD_TEST_DEMOTE_LOGIC" 

"PROB.'BILITY_TEST_DEMOTE_LOGIC" 


"GROUPS" 


"Eat  inat  ion..Predict  ion" 

"GR0UPS.ESTIMATI01I_PREDICTI0B" 

"Association" 
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"GROUPC.ASSOCIATIOH" 

"ProiBO  i:lon.D'aotion" 

'■GROUPS_PROMOTION_DEHOTIOH" 

"GROUPS_ESTIMATION_PRED1CTIOH'' 

"Cant7oid_Dyuaaical.Mod«l" 

"C0HSTANT_VEL0C:TY_DYHAMICAL_M0DEL‘‘ 
"CONSTANT_ACC£LmTIQII.DYHAMICAL_NQDEL 
"GROUPS,  VEL.PLUS.ACC_DYNAHICALJ{ODEL" 
"Measuraaont.Nodal" 

"RAE.MEAS_MODEL" 

"VAE.NEASJ!ODEL" 

"RVA£.MEAS_KODLL" 

"Plant.Noua.Modal" 

"FIXED_PLA1IT.N0ISE_M0DEL" 

"KllOWI_AHl_PUrr_llOISE^MODEL" 

"Filtar" 

"SIMPLlFlED.GAIirS.FILTER" 
"IXAST.aqUARFa  .FILTER" 

"lAUUN.FILTER" 

"Inltial_Stata.Modal" 

"aROUPS_IVIT_STATE_MODEL" 

"aRQUPS.VEL.PLUS.ACC_DYllAMICAL.MODEL" 

"Nadal.Ganaration" 

"GATE.BASED,KODEL_GEHERATIOM'' 

"Cai.3qUARE.BA3EDJ!0DEL_aElIERATI0H" 

"LIKELIKOOD.BASEDJ!ODEL_GEHERAT101I" 

"PR0BABILITY.BASED.K0DEL.GEBERAT10H" 

"Model.Scora" 

"HIT_MISSJ>ATTERB.SCORillO'' 

"CHI.SqUARE.SCORIva" 

"LIKELIHQQD.SCQRIHG" 

"PROBABiLITY.SCORIHO” 

"Model.Solaction" 

"ZER0.SCAN_DYHAI1ICAL_MQUEL_SELECTI0M" 

"N_SCAN.DYNAMICAL.MODEL_SELECTIOH" 

"Hodal.Tranaition" 

"VEL.TO.aCC.DYKAMICAL.MODZL.TRABSITIOII 

"ACC.TO.VEL.DYI(AmCAL_MODEL.TRAKSITIOM 

GR0UPS_A3SaCIATiaN" 

"Qate.Calculation" 

"RECTANOULAR.OATE.CALCULATIOH" 

"ELLIPTICAL.GATE.CALCULATIOll" 

"PARALLELOGRAM.GATE.CALCULATIOII" 

"Candidata.Ganaration" 

"GhOUPS.IMDEPEliDEirr.HYP.OEMERATIOJI" 

"GRaUPS_DEPEHDEBT_HYP_QEItERATIOB» 

" Cand idat a. 3 cor ing " 

"HIT_mSS_PATTERH.SCORIlIG" 

"CHI.SqUARE.SCORIItG" 

"LIKELIHOOD.SCORIIIG" 

"PRCBABILITY.SCORIHG" 

"Candidata.Seler.tion" 


"2_SCA»_UMC0QRD_H*IU)_3ELECTI0M" 

"PDA.HYP.SELECTIOB" 

"CR£E»y^HW_SELE''TIOH" 

"K!«IKR2S.HYP_SELECTIO)i'' 

"HUaKRES,tf_CfEA5iUP.HYP_SEIECTIOH" 

'‘CLEAHUP..HYP  .SELECTION  " 

"AUCTIO!i.HYP.SrX:;cnn!l" 

"BETrfORK.FLDH.HyP .SELECTION" 

"IhT.PEOG.HVP.SELECTlOM" 

"JPDA.HYP.SELECTION" 

"SPLITTIKG.HYP.SELECTION" 

"SPLITTING.W_MEfl:GIMG_HYP_SELECnON" 

"GROUPS.N.SCAN.COORDIMATED.SELECTIOH" 

"GROUPS.lt.SGAN.COOROIHATED.SELECTIOa*' 

"GROUPS.N.SCAH.COQRDIIiATED.SELECTIOK" 
"Kypothesift  Ganeration" 

"K.BEST.HYP.GENERATIOH" 
"ALL_ABOVE_fHRESHQLD_HYP_GEIiERATIOM" 
"Hypothasis  Selection" 

"M_3CAK_COQRD_HYP.SELECTIOll" 

"GaOUPS_PROMOTION.DEMOTIOII" 

"Initiation” 

"OH.ALL.IWT.LOGIC" 

"GATE.BASED.miT.LOGIC" 

"CHI.SQUARE.BASED.I«IT_LOGIC" 

"LIKELIHOOD.BASED.IlilT.LOGIC" 

"PRaBABILITy.BASED.IHIT.LOGIC" 

"Track.Scorin^" 

"M1T.MISS.PATTERB.SCQRI1IG" 
"CHI.SqUARE.SCORIVG " 
"LlKELIHaaD.SCORING" 
"PROBABILITY.SCORIHG" 

"PvoBote.Logic" 

"M.OF.K.PROMOTE.LOGIC" 
"CHI.SQUARE.TEST_PROHOTE_LOGIC" 
"LIKELIHOOD .TEST.PROMOTE.LOGIC" 
"PRQBABILlTy_TEST_PROMOTE_LOGIC" 
"Donote.Logic" 

"K.HISS .DEM0TE.L0GIC" 
"CHI.SQUARE.TEST.DEHOTE.LOGIC" 
"LIKELIHnOD.TEST_DEMOTE.LOCIC" 
"PROBABILITY  .TEST.DEMOTE.LOGIC" 

"FORMATIONS" 

"Estiaation.Prediction" 

"FORMATIONS.ESTIMATIOH_PREDIC'riDH" 

"Association" 

"FORMATIONS.ASSOCIATION" 

"Pr oao  t ion_DeBot ion" 

"FORMATIONS.PRUMOTION.DEMOTION" 

"FORMATIONS .ESTIMATION  J'REDICTIOB" 
"Dynanical.Hodel " 
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"COSSTAHT_VELOCITY_DyHAmCAL.MQDEL" 

"CONSTANT_ACCEIXRATIOM.DYHAMICAL_MODEL" 

"FORMAT10IIS_VEI,_PLUS_ACC_DYNAMICAL_MODEL" 

"Heasureaent.Model" 

"RAE.KEAS .MODEL" 

"VAE_MEAS_HODEL" 

"RVAE_MEAS_MODEL" 

"Plant.Noi8e_Modal" 

"FlXED_PLAliT_KOISE_MQDEL" 

"KliOWE.AMl.PUirr_NOISE.MODEL" 

"Filter" 

"SIMPLIFIED.GAiaS.FILTER" 

"LEAST.SO'JARES.FILTER" 

"KALMAa_FILTER" 

"Initial.State.Modal" 

"F0RI!ATI0MS.IS3;T.STATE.M0DEL" 

"F0RMATIOllS_VEL_PLUS.ACC.DYMAMICAL.M0DEL" 

"Moda 1 .Oenarat ioQ " 

••GATE.BASED.MODEL.GEKEBATIOII" 

"CHI.SQUARE.BASED.MODEL.GEltERAT’-Olf 

''LIKELIH000_BASED_N0DEL.aEl(ER4TIQN" 

"PR0BABILITY.JASED.M0DEL_GEHERATI0N" 

"Modal.Score" 

"H1T.MISS_PATTER1I_3CQRIHG" 

"CHI.SQUARE.SCQRIMG" 

"LIKELIHOOD.SCQRIHG" 

"PROBABILITY.SCORING" 

"Nodel.SalactioD" 

"2ER0.SCAII.DYKA1IICAL_M0DEL.SELE‘JTICH" 
"M.SCAli.DYl(AMlCAL.MODEL,SELECTIO«" 
"Kodel.Tranait ion" 

"VEL.Tfl.ACC.PYIIAFtlCAL.MODEL.TRAMSITIOM" 

"ACC_T0_VEL.DY1IANICAL_M0DEL.TRANSITJ.0N" 

"FORMATIOl'S.ASSOCIATIOK" 

"Gate.Calculation" 

"  HECTANGUUR.GATE.CALCULATIOM" 

"ELLIPl  ICAI.  .GATE.CALCUUTIQK" 

■  PARALLELCGRAM_GATE_CALCUUTIOH" 
"Co;£relation“ 

"FORMATIOKS.  .TEMPLATE.CORh" 

•'FORMATiaBS  .STATISVICAL.CORB" 
"FOHNATIOKS.INTEUTRACK.CORR" 

"KORMATIOHS.PhOMOTIOB.DEMOTION" 

"Initiation" 

"OS_ALL_IIIIT_LOGIC" 

"GATF.r^ASED.IKIT.LOGIC" 

" CHI.SQUARE.BASED.INIT.LOGIC" 

" LIKELIHOOD.BASED.IKIT.LOGIC" 

"PROBABILITY .BASED.IHIT.LOGIC" 
"Track..Scorixig" 

"Hr  J-iISS_PATTERN_SCORIHG" 

" CHI.SqUARE.SCORIMG " 
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“LIKELIHOOD.SCOamO" 

"PROBABILITY.SCORIHG" 

"FroBote.Logic " 

"M_QF_H.PR0H0TE_L0aiC" 

"CHI_SQUARE_TEST_PROMOTE_LOOIC" 

'‘LIKELIHOOD_TEST_PROMOTE_LOGIC" 

"PROBABILny_TEST_PROMOTE_LOGIC" 

"D«iiote_Logic" 

"K_M1SS_DEH0TE_L0GIC" 

"CHI.SQUARE.TEST.DEMOTE.LOGIC" 

"LIKELIHOOD_TEST_DEMOTE_LQGTC" 

"PROBABILITy_TEST_DEMOTE_LOGIC“ 

"CLUTTEft.DISCRETES" 

"Est iMat ion_Pr edict ion" 

"CI,UTTER_ESTIMATI0H_PREDICT10M" 

"Aaaociation" 

"CLUTTER_ASSOCIATIOH" 

"Proiiotiau.Oaaotiou" 

"CLUTTER_PR0M0TI01I.DEM0TI0H" 

"CLUTTER_ESTIMATI0N_PREDICTI01I" 

"Dynanical.Hodel" 

"COII3TANT.VELQCrTy_DyilAmCAL_MOOEL" 
"COMSTANT_AC';ELERATIQM_DyitAMICAL.MODEL" 
"CLUTTER.  VEL.PLUS_ACG_DyHAMICAL_MODEL" 
"Ma asur eaent .Node 1 " 

"RAE.MEAG.MODEL" 

"VAE.MEAS.MQDEL" 

"RVAE.HAS_MODEL" 

"Plant  _t.'oia«_Hodal" 

"F1XED_PLAHT_N0ISE_1!0DEL" 

"KKOWII_AM1_PU1IT_NOISE.NODEL" 

"Filter" 

"SIMPLIFIED.GAIHS.FILTER" 

"LEAST.SqUARES.FILTER" 

"KALHAN.FILTER" 

"Initial.State.Hodel" 

"CLUTTER.INIT_STATE_HODEL" 

"CLUTTER.  VEL_PLUS_ACC_DY1IAMICAL_M0DEL" 
"Modol.Generation" 

"GATE.BASED.HODEL.GEIIERATIOII" 

"CHI.SQUARE_BASED_MODEL_GE»ERATION" 

"LIKELIHn0D_BASED_(I0DEL_OE«ERATI01l" 

"PROBABILITy.BASED.MODEL_OEllERATIO»t" 

"Model.Score" 

" HIT_MISS_P ATTERH.SCORIMG " 
"CHI.SQUARE.SCORING" 
"LIKELIHOOD.SCORING" 
"PROBABILITY.SCORIHG" 

"Hodel.Selection" 

"ZERO_SCAN.DyHAMICAL_MODEL_SELECTIOH" 
"H_SCAH_DyNAMICAL.MODEL_SELECTIO«” 
"Model.Traiiait  ion" 
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"VEL.';Q,ACC.DYHAMICAL_M0DEL_TIUL1ISITI0N" 

"ACC_T0.VEL_DYHAMICAL_M0DEL_TRA«SIT10JI" 

"CLUTTER_ASSOCIATIOH" 

"Qata.Calculatlon" 

"RECTAMGUUR.GATE_CALCULATI01I" 

"ELLIPTICAL_GATE_CALCUUTI01I" 

"PARALLELOGRAM_aATE_CALCUUTION" 

"C&ndidats.Genaration" 

"OATE.BASED.CANDZDATE.GENERATXOH" 

"CHl.SQUriR£_BASEO_CAHOIDATE.aEIIERAnOX" 

"LIKELlHOOD.BASED„CANOIDATE.OEllERAnON" 

"PR0BABILITY_BASED_GAIfDIDATE_GENERAT10X" 

"Candidata.Scorliig" 

"KIT.MISS_PATTERfc_SCORIHO" 

"CHI.SqUARE.SCORIHO" 

"LIKELIHOOD.SCORIHG" 

"PROBABILITY.SCORIHO" 

"Caadidata_S«lection" 

"Z.SCAN.UMCQORD.HARD.SELECTION" 

"PDA_HYP„SELECTIOM" 

"QREEDY.HYP.SELECTIOM" 

"MUXKRES.HYP.SELECTION" 

"MUltKRES.W.CLEAlIUP.HYP.SELECTIQK" 

"CLEAlfUP_HYP_SELECrriaM" 

"AUCTIOH.HYP.SELECTIOX" 

"!IETWORK_FLOW.HYP_SELECTIOM‘’ 

"IMT.PROG.HYP.SELECTIOM" 

"JPDA.HYP.SELECTIOM" 

"SPLITTIIIG.HYP.SELECTIOK’' 

"SPLITTIlIO.WJiEROIXG.HYP.SELECTIOX" 

"CLUrrER.K.SCAB.COORDIMATED_SELECTIOH" 

"CLUTTER_N.SCAK„COORDIMATED.SELECTIOH" 

"CLUTTER_B_SCAM.COORDINATED.SELECTIOM" 
"Hypothaaia  Generation" 

"K.BEST.KYP.GEMERATIOH" 
"ALL.ABOVE_THRESHOLD.HYP_GEHERATION" 
"Hypothesis  Selection" 

"lt_SCAlI_COORD_HYP.SELECT.ION" 

"CLOri'ER.PROHOTIOH.DEMOTION" 

"Initiation" 

"ON.ALL.INIT.LOGIC" 

"GATE.BAP’^^'O.INIT.LOGIC" 

"CHI.SUUAl^.BASED.INIT.LOQIC" 

"LIKELIHOOD.BASED.INIT.LOGIC" 

"PROBABILITY_BASED_I«IT_LOGIC" 

"Track.Scoring" 

"HIT.MISS_FATTERH_SCORI*G'' 

"CHI.SQUARE.SCOKING" 

"LIKELIHOOD.SCORING" 

"PROBABILITY.SCCRIMG" 

"Proaote.Logic" 

..-0F_N.PR0M0TE.L0GIC" 
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‘'CHI_SQUARE.TEST_PROMOn:_UGIC'' 

"LIKELIHOOD_TEST_PRO«OTE_LOaiC" 

"PROBABILlTY_rEST_PROMOTE_LOOIC" 

"Denote.Loglc" 

"K_MISS_UEMOTE_LOGIC'' 

"CHI.SQUARE.TEST.DEHOTE.LOMC" 

"LIKELIHOOD_1EST_DEI10TE_LOGIC“ 

"PROBABILnY_TEST_DEMOTli_LQGIC'’ 

''ZER0_3GAH_SIG_?R0G"  ; 

•'N_SCAH.REED_SIO_PROC"  j 

•'II.SCAN_TEMPLATE_MATCHI1IG_SK.PR0C"  ; 

"'.ATE_BASEO_MQOEL.GENERAT1QH''  ; 

"CHI_SQUABE.BASED.«ODEL_GEMERATIOII''  ; 

"LIKELIHOOO.BASED_HUDEI-_GEI(£RATION"  ; 

‘'PROBABILITY_BASED_MODEL_GEHF.RATIOM"  ; 

‘'2ER0_SCIK.DYHAMICAL_MaDEL_SELECTIUM"  ; 

"II_SCAN.DY1I/JUCAL.M0DEL_SELECTI0N"  j 

‘'VEL.T0.ACC.DY1IAMICAL.M0DEL_TRA1ISITI0M''  ; 

"ACC.TO.VEL_DYHAMICAL.MODEL_TRAllSniOM"  j 

"RAE.MEAS_HUDEL‘‘  j 

''VAE.MEAS_MQDEL"  ; 

''RVAE_(IEAS_MODEL"  ; 

"FIXED_PLA1IT.H0ISE.M0DEL"  ; 

''RH0B1I.AM1.PUNT.H0ISEJN0DEL"  ; 

"SIMPLIFIED.GAIH3.F1LTER"  j 

"LEAST.SQUARES.FILTER"  ; 

"KAUUII.FILTER"  ; 

"SIIIOLE.OBS.DERIVED_INIT_STATE_MODEL"  ; 

"SIIIGLE_GRP_TRK_DERI VED.IHIT.STATE.HODEL  "  ; 

"COMSTAKT_VELOCITY_DYKAMICAL_I!ODEL"  ; 

"COMSTANT_ACCEI£RATIOH_DYl(AHICAL.MODEi"  ; 

"K.BEST_HYP..OE«EKATIOII'‘  j 

•'AI.L_ABOVE_THRESHOLD_HYP_OEHERATIOK"  ; 

"B.SCAH.CDORD.HYP .SELECTION"  j 

"RECIANGUUR_GATE.CALCULATION"  ; 

"ELLIPTICAL.GATE.CALCUUTIDN"  ; 

"PARALLELOGRAM.GATE_CALCULATION"  ; 

"GATE.BASED.CANDIi)ATF._GENERATIOII"  ; 

"CHI_SqUARE_BASED.CAHDIDATE_QENERATIDH"  ; 

"LIKELIHOOD.BASED.CAHDIDATE.GEHERATIOH"  ; 

"PRODABILITY_BASED_CANDIDATE.GENERATIOH"  ; 
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"Z_SCAN.UMCQORD.HAIU)„SELECTIOH" 
"PDA.HYP .SELECTION" 

"QREEDY.HYP .SELECTION" 
"MUNKRES.HYP.3ELECTI0N" 
"MUNKBES.W.CLEANUP.HYP .SELECTION" 
"CLEANUP .HYP.SELECTION" 
"AUCTION_HYP_SELECTION" 
"NETWORK.RON.HYP  .SELECTION" 
"INT.PROG.HYP.SELECTIDN" 

'•  JPDA_HYP.SELECTION  " 

"SPLITTINQ.,HYP_S£LECTION" 

"SPLITTINO_V.NERGING.KYP.SELECTION 

"OH.ALL.INIT.LQQIC" 

"GATE_BASED_INIT.LOaiC" 

"CHI.3t)UARE.BASED.IHIT.LDGIC" 

"LIKELIHOOD.BASED_INIT.LQGIC" 

"HIT.MISSJ>ATTERN.SCORINO" 
"CHl.SQUARE.SCORING" 
"LIKELIHOOD.SCQRINO" 
"PROBABILITY.SCORING " 


"M.OF_N_PROMOTE.LOGIC" 
"CHI.SQUARE.TEST.PROHDTE.LOGIC" 
"LIKELIHOOD.TEST.PROHQTE,. LOGIC" 
"PROBABILITy.TEST_PKOMOTE.LQGIC" 

"K.BISS.DEMOTE.LOGIC" 
"CHI.SQUASE.TEST.DEMOTE.LOGIC" 
"LIKELIHOOD.TEST.DEMOTE.LOGIC " 
"PROBABILITY.TEST.DEMaTE.LOGIC" 


II 

II 


GROUPS.IHDEPENDENT.HYP.GEHERATION 

GRDUPS.DEPENDENT.HYP.CENERATION" 


"GROUPS.INIT.STATE.MOUEL" 

"FnRHATIONS.INIT.STATE.HODEL" 

"CLUTTER_INIT.STATE.MODEL" 


"FORKATIONS.TEMFLATE.CORR" 

"FORMATIONS.3TATISTICAL.CORR" 

"FORMATIONS.IHTERTRACK.CORR" 
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Appendix  C.  Summary  of  Z  Notation 


LHS  =  RHS 
x:  T 
X?:  T 
x!:  T 

X 

x’ 

0 

P  X 
F  X 
S  C  T 

t  e  s 
t  ^  s 

S  UT 
S  nT 
TiXT, 

X  Y 

1  H-+  m 

2  Schema 
A  Schema 
S  <  T 
R-10  Rj 


Definition  of  LHS  as  syntactically  equivalent  to  RHS 
Declaration  of  x  as  type  T 

Declaration  of  x  as  type  T  used  as  input  to  an  operation 

Declaration  of  x  as  type  T  used  as  output  by  an  operation 

Value  of  X  before  an  operation 

Value  of  X  after  an  operation 

The  empty  set 

The  power  set  of  X 

The  finite  subset  x  of  X 

S  is  a  subset  of  T 

t  is  an  element  of  S 

t  is  not  an  element  of  S 

Set  union 

Set  intersection 

Cartesian  product 

The  set  of  partial  functions  from  X  to  Y 
1  is  related  to  m 

Include  but  do  not  change  the  schemn 
Include  and  allow  change  to  the  schema 
Domain  subtraction 
Overriding 
Such  that 


C-1 


Appendix  D.  Selected  FORTRAN  Module 


C  HONEUOtlX  PROJECT  91  -  DISCRETE  XALMAK  FILTER 
C  OPEG  BIERMAN 

C 

PROGRAH  PROJl 

C  VARIABLE  LIST 

IMPLICIT  BONE 

IHl-EOER  K,C.ll,12,IS,I0PT,NaR,NPT.J 

REAL  X(IOO)  .Y(IOO) . WC<100)  .WY(IOO)  ,IHATII(2.1)  ,XHATDLD(2,)) 

REAL  VX(100),VY(100),Z(2,1}.XHAT(2.1),ZHAT(2.1).NU(2.1> 

REAL  P(2.2),F(2,2),FT(2.2).R<2.2),P«<2.2) 

REAL  TENPl<2,2),TEMP2(2.2}.q<2,2).H(2.2).S(2.2).HT<2,2),SI(2,2) 
REAL  W(2.2).WT(2,2),XTILDE(2.1).XTILDET<1,2).EPSIL0II(1,1) 

REAL  Graph(20,200),PI(2.2) 

CHARACTER*  16  Nui«g(20) 

CONNQN  /SEED/  11,12 

11- 1234S 

12- 54321 

C  OPEN  FILES  USED  TO  STORE  DATA 

□p«a  (UnlfS .  Fila-  >  KALMAN .  PLT  > ,  FORM-  >  unloraattad  * ,  St  atua-  >n*«  * ) 
0pan(Unlt-9 . Plla- >  KALMAN . PL ' . Status- *ne* ' > 

Open (Unit-10 .File- • XTRUTH .PRN ' , Statu«-»na»') 

Open (Uttit-1 1 , Flia- ' YTRUTH .PRN  * , Status- ’nea ’ ) 
apan(Uait-12 . File- *  XMEAS . PRN ' , Status- >nev  * ) 

Open (Unit-13 .File- ' YMEAS . PRN  * .Status- 'new ' ) 

Open (Unit-14 .File- ' XEST . PRN ' , Statue- 'new ' ) 

Open (Unlt-15 . File- ' VEST . PRN ’ , Status- 'new ' } 

Open (Unit-16 , File- ' XNOISE .PRN ’ , Status- 'new ' ) 

Open (Unit-17 , File- ' YNOISE . PRN ’ , Status- 'new ' ) 

Open (Unit-20 , File- ' ZXNOISE . PRN  ’ , Statue- 'new ’ ) 

Open (Unit-21 . File- ' ZYNOISE . PRN ’ , Status- 'new ' ) 

Open (Unit-22 , File- ' P 1 1 . PRN ' , Status- 'new ’ ) 

Open (Unit-23 , File- ’ P22 . PR* ’ . Status- 'new ' ) 

Open (Unlt-24 . Fil e- ’ EPSILON . PRN ’ , Statue-  'ncr ' ) 

Open (Unit-26 , File- ’ XTILDE . PRN ’ , St atus- 'new ' ) 

C  START  MAIN  PROGRAM  (73  POINTS  COLLECTED) 

C  -  73 

C  COMPUTE  MODELLING  NOISE  (SET  TO  ZERO) 

DO  K-1,C 

CALL  N0ISE(0.0,UX(K).12) 

CALL  NQISE(0,0,VY(K),12) 

»rite(16.*)  VX(K) 

Write (17,*)  WY(K) 
end  do 

C  SET  INITIAL  VALUES 
X(l)-10.0 

y(i)-o.o 
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Z(l.l)-10.0 
Z(2.1)*0.0 
P(l,l)  -  1.0 
P(l,2)  -  0.0 
P(2,l)  -  0.0 
P(2,2)  -  1.0 
F(l,l)  ■  COSD(B.O) 

F<1,2)  -  -0.6*SIMD<6.n) 

F(2.1)  -  2*SIHD(5.0) 

F(2,2)  -  C0SD(5.0} 

CALL  MTXTRP  (F.FT.2.2) 

Qd.l)  -  0.0 
Q(l,2)  -  0.0 

q<2,l)  -  0.0 

Qi:2,2)  -  0.0 
Hd.l)  -  1.0 
Hd,2>  -  0.0 
H(2,l)  -  0.0 
H(2,?)  -  1.0 
CALL  MTXTRP  CH.HT,2,2) 

Rd.2)  -  0.0 
R<2,1)  -  0.0 
IS  -  0 

XHATOLOd.l)  -  10.0 
XHAT0LD(2,1)  -  0.0 

C  START  MAIN  LOOP 
DO  K-l.C 

C  WRITE  INITIAL  VALUES  TO  FILES 
Grapbd.K)  -  K 
Vrit«d0.*)  X(K) 

Wrxt«dl,*)  Y(K) 

Gr(ipb(2,X)  -  X(K) 

0r«ph<3,K)  -  Y(K) 
arapb(4,K)  ■  ZCl.l) 

GrapbCB.K)  -  Z(2,l) 

Writed2,*)  ZCl.l) 

Writed3.*)  Z(2.1) 

Graph<8,K)  -  Pd,l) 

Grapb(9,K)  -  P(2,2) 
tfrita(22,*)  Pd.l) 

Vrite(23,*)  P(2,2} 

Gi-apb(6,K}  -  XNATOLDd.l) 

Grapb(7,K)  •  XHAT0LD(2,1) 

Hrit«d4.*)  XHATQLDd.l) 

VritedB,*}  XHAT0LD(2.1) 

C  NORMALIZED  STATE  ERROR  (EPSILON  -  XTILDET*PINV*XTILDE) 

C  XHATOLD  -  XHATN 

XTILDEd.l)  -  X (K) -XHATOLD d.l) 

XTILDE(2,1)  ■  Y(K)-XHAT0LD(2,1) 

CALL  MTXTRP  (XTILDE.XTILDET.2,1) 

CALL  MTXINV(P,PI,TEMP1,2.IS) 

CALL  MTXM0L(XTILDET.PI.TEMP1.1.2.2) 
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CALL  MIXMUL (TEMP 1 , XTILDE ,EPSILOH ,1,2,1) 
6rapb(10,K)  -  EPSILON(l.l) 

Writ«(24,*)  EPSILONd.l) 
araph(U,K)  -  XTILDE{1,1) 

Wrjte(26,*)  XTILDE(1,1) 

C  STATE  PREPICTIOK;  XiiAT  -  F#XHATOLD 

XHAT(l.l)-F(l.i)*XHATQLD(l,l)+F<l,2)*XHAT0LD(2.1) 

XHAT12.1)«F(2,1)*XHAT0LD(1,1)+F(2,2)*XHAT0LD(2,1) 

C  TRUTH;  X(K+1>  -  F*X(K) 

X(K41)  -  F(l,l)*X(K)+F(i,2)*Y(K)+«X(K) 

Y<K+1)  -  V(2,l>*X(K)+F(2,2)*Y<r)+VY<K) 

C  COMPUTE  MEASUREMEHT  NUISE 
iid.l)  -  0.2'>ABS(X(K+1)) 

R(2,2)  -  0,2*ABS(Y(K+1)) 

CALL  H0IS£(0,Rd,l),VX(Kd),12) 

CALL  il0IS£(0,R(2.2),VY(Kd),12) 

Vrlta(20,*)  VX(K-M) 

Writo(21,*)  VY(K+1) 

Graphd2,K+l)  -  VX(K+1) 
araplid3,K+l)  -  VY(K+1) 

C  MEASUREMENT i  Z  -  X+V 

Zd,lX(X+l)+VX(K+l) 

ZC2,1)-Y(K+1)+VYCK+1) 

C  MEASUREMENT  PREDICTION  (ZHAT-H*XHAT) 

CALL  MTXMUL(H,XHAT,ZHAT,2,2,i) 

C  INNOVATION  (NU-Z-ZHAT) 

CALL  NTXSUB(Z,ZHAT,NU,2,1) 

C  STATE  PREDICTION  COVARIANCE  (P-F*P*FT+Q) 

CALL  MTXHUL<F,P,TEMP1,2,2,2) 

CALL  NTXM0L(TEMP1,FT,TEMP2.2,2,2) 

CALL  HTXADD(TEMP2,Q,P.2,2) 

C  INNOVATION  COVARIANCE  (S-H*P*HT+R) 

CALL  HTXMUL(H,P,TEMP1,2,2,2) 

CALL  HTXMUL(TEMP1,HT,TEMP2.2,2,2) 

CALL  MTXADD(TEHP2.R,S,2,2} 

C  FILTER  GAIN  (W-P*HT*SI) 

CALL  MTXZNV(S,SI,TENP1,2,IS) 

CALL  MTXMUL(P,HT,TEMP1,2,2,2) 

CALL  MTXMUL(TEMP1,SI,V,2,2,2) 

C  UPDATED  STATE  COVARIANCE  (PN-P-W*S*WT) 

CALL  MTXTRP  (W,WT,2,2) 

CALL  HTXMUL(V,S,TENP1,2,2,2} 

CALL  HTXMUL(TEMP1,WT,TEMP2,2,2,2) 

CALL  MTX3UB(P,TEMP2,PN,2,2) 

Pd,l)  -  PNCl.l) 
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P(1.2)  -  PN(1.2) 

P<2,1)  -  PN(2,1) 

P(2,2)  -  PH(2,2) 

C  UPDATED  STATE  ESTIMATE  (XHAT»-XHAT+tf*NU) 

CALL  MTXMUL(W,MU,TEHP1.2,2,1) 

CALL  HTXADDCXHAT, TEMPI. XHATH. 2,1) 
XHATOLDd.l)  -  XHATN(l.l) 

XHAT0L0C2,1)  -  XHATH (2.1) 
end  do 

C  PLOT  ROUTIME  FOR  OUTPUT  DATA 
NGR-IS 

Naaeg(l)  <•  'X* 

Nuttg(2)  -  'X  TRUTH’ 

NiUBegO)  -  'Y  TRUTH’ 

NaBeg(4)  -  ’X  MEASURED’ 

NaaegCB)  -  ’Y  MEASURED’ 

NamegCe)  -  ’X  ESTIMATE’ 

NaMeg(7)  «  *Y  ESTIMATE’ 

NoMegCe)  -  ’Pll,  X  COVAR’ 

NaaegO)  •>  >P22,  Y  COVAR’ 

NaaegClO)  -  ’EPSILOH’ 

Naaeg(ll)  -  ’XTILDE’ 
llaBeg(12)  -  ’KEAS  NOISE  X> 

MaaegdS)  -  ’HEAS  NOISE  Y’ 

IQPT  -  1 
HPT  -  73 

WRITE (8)  HOR.HPT.IOPT 
WRITE(8)  (Na»eg<j),j-1,HGR) 

WRITECS)  ((Or«ph<j,k),k-l,NPT),j-l,N(}R) 
WRITEO,*)  HOR.HPT.IOPT 
WRITEO.*)  (Haaa6(j).j-1.MGR) 

WRITE ( 9 , • )  ( (Or aph  < j , k) , k- 1 . HPT) , j -1 , HGR) 

C  CLOSE  DATA  FILES 
Close (8) 

Closed) 

Close (10) 

Closedl) 

Close (12) 

ClosedS) 

Clc&e(14) 

Close (16) 

Close (16) 

ClosedT) 

Close (18) 

Close (19) 

Close (20) 

Close (21) 

Close (22) 

Close (23) 

Close (24) 

Close (26) 
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End 


C 

C  THIS  PROGRAM  CALLS  RANDOM  GENERATOR  TO  GENERATE  GAUSSIAN  NOISE. 
C 

C  N  is  set  12 

C 

SUBROUTINE  NOISE (XMEAN, VARIANCE, HNOMN.H) 

REAL  A, Y.REDMN, XMEAN, VARIANCE 
INTEGER  N 

COMMON  /SEED/  11,12 
A-0.0 
DO  1  I-1,N 
Y-RAN(I1,I2} 

A-A+Y 

00001  CONTINUE 

RNDMN-  (A-N«0 . 6)  *SQRT(  VARIANCE)  -hXMEAN 

RETURN 

END 


C**************  SUBROUTINES  OF  MATRIX  OPERATIONS  *«**••*•*•*•**■» 

C 

SUBROUTINE  MTXMUL  (A,B.C.H1,N2,H3) 

C  A  IS  N1«N2;  S  IS  N2*N3;  C  -  A«B  IS  N1*N3 


real  A(N1,N2),  B(N2,N3).  C(N1,N3) 

DO  I  -  l.Nl 
DO  J  «  1,N3 
C(I,J)  -  0.0 
DO  K  -  1,N2 

C<I,J)  -  C<I,J)+A<I,K)*B<K,J) 
end  do 
end  do 
end  do 
RETURN 
END 

SUBROUTINE  MTXADD  (A,B ,C,N1 ,N2) 

C  C  -  A+B;  ALL  ARE  N1*N2 

real  A(N1,N2),  B(N1,N2),  C(N1,N2) 
DO  I  -  1,N1 
DO  J  -  1,N2 

0(1. J)  -  A(I.J)+B(I.J) 
end  do 
end  do 
RETURN 
END 

SUBROUTINE  MTXSUB  (A,B.C.N1.N2) 

C  C  -  A-B;  ALL  ARE  N1*N2 

real  A(N1,N2),  B(N1.N2).  C(N1,N2) 
DO  I  -  1,NJ 
DO  J  -  1,M2 

C(I,J)  <■  A(I,J)-e(I,J) 
end  do 
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end  do 
RETURN 
END 

SUBROUTINE  MTXZRO  (A,N1,I!2) 

C  A  -  0;  A  IS  N]«N2 

real  A(N1.N2) 

DO  I  -  1,N1 
DO  J  -  1.H2 
Ad.J)  -  0.0 
end  do 
end  do 
RETURN 
END 

SUBROUTINE  MTXTRP  (A.B,NI.N2) 

C  B  »  TRANSPOSE  OF  A;  A  IS  H1*N2  AND  B  IS  N2*N1 

real  A(N1.N2) ,  B(N2.N1) 

DO  J  -  1.N2 
DO  I  -  1,N1  ■ 

B<J.I)  -  A(I.J) 
end  do 
end  do 
RETURN 
END 

SUBROUTINE  MTXINV(A.AINV.B.KC,IS) 

C  AINV«INVERSE  OP  A,  BOTH  ARE  KC*KC 

C  B  IS  A  VORXING  ARRAY 

C  WHEN  IS-O,  SUCCESSFUL  RETURN.  IS-1  A  IS  SINGULAR, 

c 

real  A(KC.KC)  ..MUV(KC.KC) ,B(KC,KC) 

REAL  TEMP. COMP .EPSKIP 

N-1 

IS-1 

EPSKIP-l.OE-36 
DO  1  I-l.KC 
DO  1  J-1,KC 
AIHV(I,J)-0.0 
00001  B(I,J)-A<I,J) 

DO  2  I-l.KC 
AINV(I,I)-1.0 
0C002  CONTINUE 

DO  3  I-l.KC 

COHP-0.0 

K-I 

00006  IF ( ABS  (B (K , I) ) -ABS (COMP) >6.6.4 
00004  COMP-BCK.I) 

N-K 

00006  K-K+1 

IF(K-KC)6.6.7 
00007  IFCB(N,I))8.B1.8 

00008  IF(N-I)61.12.9 

00009  DO  10  n-l.KC 
TEMP-B(I.M) 
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00010 

00013 


00013 


00014 

OOOIB 


00030 


00017 

00016 

00003 

OOOSl 

00082 


B(N.M)-TEIIP 

TEMT-AINVCI.H) 

Am(I,H)-AIilV(N,M) 

AINVCN.Ml-TEMT 

CONTIKUE 

TEMP-B(I,I) 

DQ  13  H-1,KC 

AINVd  ,M)-AMV  (I  .M)  /TEMP 

B(I  K)»B(I,M)/TEMP 

DO  16  J-1,KC 

IF(J-m4,16,14 

IF(B(J.I))lB,lfi.lb 

CONTIHTJE 

TEMP-B(J,I) 

DO  17  N»1,KC 

IF(ABS(TEMP).LT.EPSKI?)GO  TO  17 
lF(ABS(Ai;iIV(I,N)).LT.EPSKIP)GO  TO  30 
AIHV(J,M)-AIHV(J,N)  -TEMP*AHI  V  (I ,  N) 
COHTIMUE 

IF(ABS(B(I.N}).LT.EP&KIP)QO  TO  17 
B(J,N)-B(J.N)-TEMP*B(I,H) 

COHTIirUE 

CONTINUE 

CONTINUE 

RETURN 

WRITE(6.S2) 

F0RMAT<5X,'THE  MATRIX  IS  SINGULAR’) 

IS-0 

RETURN 

END 

SUBROUTINE  lOENTX  (A.N) 

A  IS  N*N 
real  A(N.N) 

DO  I  -  l.N 
DO  J  -  l.N 

A(I,J)  ■  0.0 
IF(I.EQ.J)  A(I,J)  -  1-0 
end  do 
and  do 
RETURN 
END 
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Appendix  E.  Developed  ClDL  Module 


let 

incIuLv.  Array; 
include  matrix: 
include  matrixop; 
include  noise; 
•include  "matb.cdl"; 


-  VARIABLE  LIST 
ddt 

iS8 

f ive2rad 
il 

k.  iopt,  ngr,  j,  c,  npt,  i2 
X,  y,  ex.  wy 
xbatn,  xhatold 
tx,  vy 

z,  xbat,  zhat,  nu 
p.  f,  ft,  r,  pn,  »,  Bt,  pi 
tempi,  tamp2,  q,  h,  s,  ht,  si 
>  tilde 
' tildet 

-  epsilon  o  matrix. create (real, 
■pailon 
'prapb 
nameg 


:  storeCbool): 

:  store (bool); 

:  store (real); 

:  store (real); 

:  store (tnt); 

■  array .create (real,  100); 

•  matrix. create (real,  2,  1, 

■  array .create (real,  100): 

>  Batrix_create(real,  2,  1, 

natriz_create(real,  2,  2, 
■<  Batriz.create(read,  2,  2, 

•  matrix.craatefreal,  2,  1, 
«  matrix.create(raal,  1,  2, 


-  debug  variable  only 


—  changed  from  integer 


0.0): 


O.Ol; 

0.0): 

0.0); 

0.0): 

0.0): 

1 ,  1 ,  0 . 0) :  —  there  was  a  problem  vitb  dimension  in  matmul 

■  matrix.create(real,  2,  2,  0.0); 

■  matrix.create(int,  20,  200,  0.0);  —  vae  real 

-  array. create  (string,  20); 


—  OPEN  FILES  USED  TO  STORE  DATA 

£8  :  streaa(char)  »  create(cbar,  "kalman.plt")  :  —  need  to  use  create  instead  of  open 

f3  :  Btrfl9e(char)  «  create(char,  "ialmn.pl") : 

flO  :  stre.'jt'.cbax)  ■  create(char,  "xtr^ttb"); 

a1.  :  streiai(chaz)  «  create(cbar,  "ytr.ith’'); 

fl2  :  stre3u(cbrr)  ~  create (char,  "xmeas"): 

f.'.3  :  8trca»;U>  ax  :■  ■  create(chav',  "ymeas"): 

fl4  :  f  reok  'char)  ■  create(char,  "xest"); 

fl5  ;  etreaiivchar)  <■  create(char,  "yest"); 

tld  :  iitrear(chax)  «  cxeate(char,  "xnoiee"); 

fl7  :  stream(ch..rj  ^  creatoCchar,  "yuoise"); 

f20  ;  stream(chw:)  >■  createtchar,  ''zxnoise") : 

f21  ;  .’'treaB(cha:A)  •>  create(char,  "zynoise"): 

f22  •  st.ream('-har)  •  craate(char,  "pll"); 

123  :  streamCchar)  >  create (char,  "p22"); 
f24  :  strean(i-.har)  create(chai,  "epsilon"); 
f26  ;  streaa(cbar)  '•  createCchar,  "xtilde"); 

in 

—  put  here  to  label  the  files 
loiwat(f8, "KALMAN. PLT'X'X") ; 

‘ormat (f 9 ,"KALMAa .PL'X'“") ; 

X  treat (f i 0 , " XTRUTH . PRN-* 'X" ) : 

.'<.rrat(fll."YTRUTH.PRN'X'r): 
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forBat(fl?!."XHEAS.PRN*r%") ; 
loraatCf  13,''YMEAS.PIU|-X'X") ! 
fon»at(f  14,"XES1  .PRH'VX") : 
fon<at(fl6."YEST.PWI-X*X")  i 
lor»at(fl6,"M0ISE.PRM‘X*X"): 
for»at(f  17.-'YllOISE.PRH*y.*?i") : 
±or»at{f20."ZXN01SE.PRS’X'5C' 0  : 
for»at(i21."2YNDISE.PIU|-X-X'0 : 
for»at(f22."Pll.PRH‘VX")  ; 
ioniat(123."P22.Pa3(-X-r)  : 
for*at(f24."EPSIL01I.PRl!-X"X'‘;' : 
for»at(f26."mL0E.PRH'X*X")  i 

4dt  falae;  —  debugging  flag 


~  START  HAIM  PROGRAH 


-il 

il 

1234&; 

1.0; 

—  aaad  couataut. 

too  largr,  ganarataa  0  <  i  <  1234E 

12 

54321; 

—  aaad  constant 

c 

73: 

(MUNBER  Foirrs 

COLEECTEO} 

~  COKPUTE  HGOEL1II&  MOISE  (SET  TO  ZERO) 
k  Ij 

«x.iiiltlallza(0.0):  —  t«at  only 
«y .  initializ«(0.0)  ;  —  t«at  only 

vz.initializaCO.O);  —  %«st  only 
vy.iaitializcCO.O):  —  only 

loop 

«h<an  content  (k)  <■  cont«nt(c)  «> 

«z.aa»ign(k,  ■al:«tioi5«(0t  0,  12,  il}};  ••  had  to  bo  rowrlttaa  coaplotoly 
«y.adelgs(k,  cakonoisoCO,  0,  1?,  il}};  —  «a  an  asaiga  inataad  ol  paaaing 

—  the  array  alaaost  to  cbango 

loi-BatCliS,  “'d  ’X",  ax.iadax(k}}: 
iorBat(lll7,  "'d  *1",  ay.  lnd«x(k}}  ; 
k  k  +  1 
«tkd  loop; 

—  SET  IMITIAL  VALJES 
r  .iniiializ'tCO.O}  ;  -  t«nt  only 

x. aaaignd,  10.0); 

11  coat<uit(ddt}  thoD  --  if  atatasaat  for  dobugging/daT«lo|iMnt 

fozMt(tai:Binal.‘'~'ax  array  -  "}; 

x.printO 
and  il; 

y .  ir.itializuCO.O}  :  —  taat  only 

y. aaaignd,  0.0}; 

if  concant(ddt}  than  —  if  atataaant  for  dabugging/davalophont 

fomat('^'<rwnal,"'Xy  array  -  "}; 
y  .prints, 
and  if ; 

z. aasignd,  1,  10.0.'; 

z.aaaign'2,  1,  0.0}; 

il  contautCddt)  than  —  if  atataaant  for  dobugging/daralops'int 
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loraat(t«rMiiial,''~Xz  aatrix  -  ; 

z.printO 

end  if; 

p.assignd,  1.  1.0); 
p.assignd,  2,  0.^); 
p.a«sign(2,  1,  0.0); 
p.as*ign(2,  2.  1.0); 

if  content  (adt)  than  —  ii  atatenent  lor  debugging/developeent 

lonMt(tarBinnl,"p  nntriz  ••  ") ; 
p.printO 
end  if; 

fiva2red  :■  2*Mth.pi*6. 0/360;  —  the  IPORTRAV  celled  lor  degreaa,  LISP  uaes  rediana 

l.eaaignd,  1,  nath-coaditeZrad)) : 
l.aaaignd.  2,  -O.E  a  wath.aindiaeZrad)) ; 
l.aa8ign(2i  1.  2  «  Mth.aindiTeZrad)) ; 
l.aaaign(2.  2.  nath.coadiveZrad)) : 

il  content  (ddt)  then  —  il  atateaent  lor  debuggin^devalopaent 

lonutCterainal,"!  ndtriz  •  "): 
l.printO 
end  il; 

■atrix.tranapoaad.lt) ! 

il  content  (ddt)  then  —  il  atatenent  lor  dabugging/developaent 

loi'aat(tez«iiial,“l  natriz  tranapoac*  “)i 
It. pr  into 
end  il; 

-*  q.  initialize (0  0):  ~~  not  needed 

il  content  (ddt)  then  *-  il  atateaent  for  dabugging/deralopaent 

lonat(terainal."q  aatriz  ■  '') ; 

(l.printO 
end  il; 

h.aaaignd.  1,  1.0); 
h.aaa7.5n(l,  2,  0.0); 

h.aaai((n<2.  1,  0.0); 
h  uaign(2.  2.  1.0); 

il  content  (ddt)  then  —  il  atateaent  lor  debugging/deTelopjent 

loraat(terainal,"b  aatriz  ■  "); 
h.printO 
end  if; 

aatriz.tranapoae(b,ht} ; 

il  content  (dit)  than  —  il  atateaent  lor  debugging/developaant 

format  (tarainal  I "h  aatriz  tranapoae*  "); 
ht.printO 
end  if; 

r.aaaignd,  2.  3.0); 
r.asBign(2.  1,  0.0); 

il  content  (ddt)  then  —  il  etateaent  loT  debugging/developaent 

format  (terminal, 'r  aatriz  ■  "); 
r  .printO 
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end  if; 


ies  faloe; 

xbatold.aesignClt  1,  10.0); 
xhatold.aMign(2,  1,  0.0); 

if  content  (ddt)  then  *—  if  atateaent  for  dabugging/developaent 

fomat (terminal, "zhatold  matrix  ■  ") : 
zhatold.printO 
end  if; 

—  START  Hill  LOOP 
k  1: 
loop 

-  •  WRITE  miTlAL  VALUES  TO  FILES 
•ban  content  (k)  <■>  content  (c)  •> 

format (terminal,  ""d*X",  content (k));  —  monitor  loop  progreaa 

graph. aaaignd,  k,  k)  : 

format(fl0,  "‘d  ~X",  z.indaz(k)): 

foraat(fll,  “'d  "X",  ]r.ind«z<k)) ; 

grapb.ammign(2,  k.  x.ihdez(k)); 

graph. aasignO,  k.  y,lndez(k)); 

graph.aaaign(4,  k.  z.indezd,  1)); 

graph. amaign(S,  k,  z.indez(2,  1)); 

format(fl2,  “*d  “t" ,  z.indezd,  1)}; 

formmt(fl3,  ''-d  T.  2.indez(2,  D); 

graph. aesignCS,  k,  p.indezCl,  D); 

graph. uaign(9,  k,  p.indaz(2,  2)); 

format(f22,  "~d  p.indezd,  1)); 

lozmmt(f23.  "'d  p.indaz(2,  2)); 

graph. aaaign(6,  k,  xhatold.lndezd,  O): 

graph. aaaignCT,  k,  zbatold.indez(2,  1}); 

fozmmt^fld,  "~d  ~X''.  xhatold.indazd,  1)}; 

format <f 16,  "'d  ~X",  xhatold.  indez<2,  i)}; 

—  aORMLIZEO  STATE  ERROR  (EPSILOl  -  XTIU)ET«PIIV*XT1LLE) 

"  XHATOLD  -  XHATM 

ztilde.asaignd,  1,  z.indez(k)  -  xhatold. indexd.  1)); 
ztllde.amaigu(2,  1,  jr.indczCk)  -  xhatold. indas(2,  1}); 
matrix.tranapose (zt ilde , zt ildat ) ; 

if  content  (ddt)  and  content  (k)  «  1  then  —  if  atatamant  for  dabugging/deTalopaant 

put ("zt ilde"); 

zt  ilde,  pr  into ; 

put ("zt ildat"); 

zt  ildat.  pr  into 

end  if; 

matriz_inT(p.  pi.  tempi);  ~  changed  the  tempi  to  isa 
matrix_inT(p,  pi,  lea); 

if  cont''nt(ddt)  and  content  (k)  ■>  1  than  if  atatamant  for  debugging/da valopment 

putCy): 

p.printO; 

putC'pi"); 

pi.  pr  into ; 

putC'laa"); 
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putdsB) 
end  if; 

■atrix_itult(xtildet,  pi,  tenpl); 

if  content  (ddt)  and  content  (k)  “  1  then  --  if  stateiient  for  debugging/developeent 

putC'itildet") : 

xtildet. print (} ; 

put ("pi"); 

pi.printO ; 

put ("tenpl"): 

tempi,  pr  into 

end  if; 

natrix.Bii'lt (tempi,  xtilde,  epsilon); 

if  content  (ddt)  and  content  (k)  -  1  then  —  if  statement  for  debugging/development 

put ("tempi"): 

tempi. print 0 ; 

put  ("xtilde") ; 

xtilde. print () ; 

put ("epsilon") ; 

epsilon. pr  into 

end  if; 

graph. aasign(  10.  k,  epsilon,  indexd,  1)); 
for«at(f24,  "~d  'X",  epsilon. indexd,  1)); 
graph. assigndl,  k,  xtilde. indexd.  1)); 
format (f 26.  "‘d  *X".  xtilde. indexd,  1)); 

STATE  PREDICTIOB  (XHAT  -  F^XHATOLD) 
xhat . asaignd ,  1,  f. indexd,  l)*xhatold. indexd,  1) 

4-  f. indexd,  2)«xhatold.index(2,  1)); 
xhat.ammi>gn(2,  1,  f.index(2,  Dexhatold. indexd,  1) 

*  f.indox(2,  2)*xhatold.index(2,  1)); 

if  content  (ddt)  and  content (k)  -  1  then  --  if  statement  lor  debugging/deeelopment 

putC'xbat"): 

xhat.  pr  into 

end  if; 

TRUTH  (X(I+i)  -  1*X(«)) 

x. assign(k4’l,  f. indexd.  Dex.index^k) 

4-  f. indexd,  2)«y .  index(k) 

4-  wx.index(k)) ; 

y.  assign (k4-l ,  l.index(2,  l)ex.index(k) 

4-  f.indos(2,  2)ey.indcx(k) 

4’  my.  indox(k)) ; 

COMPUTE  NEASUREMEMT  HOISE 
r.assignd,  1,  0.2*math.aV)B(x.index(k4^1))); 

r.assign(2,  2,  0.2*Math.abs(y.indax(k4-})});  —  bad  r(r,l)  not  r(2,2) 

TX.assign(k  4-  l,  Bakenoisa(0,  r. indexd,  1),  12.  il));  --  error  in  type  caused  problem  here 

vy.asBign(k  4-  i,  Bakenoiss(0,  r.indez(2,  2),  12,  il)): 

lormat(f20,  "*d  "X",  TZ.index(k  +  1)); 

loraat(f2i.  "*d  "X",  Tjr.indexf.k  *  1)); 

graph. aBsignd2,  k4’l,  ex. index (k4-l)) ; 

graph. amsigndS,  k4-l,  ey . index(k4'l)) ; 

KFaSUREHEHT  (Z  -  X4-V) 

z. assignd.  1,  x.index(k4-l)4'Tz.ind«x(k4-l)}; 
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z.a8Blgn(2,  1,  y.indeiCk+lJ+vy.iiKlaxCk+l)); 


—  K£ASUR£H£irr  PREDICTION  (ZHAT  -  H*XKAT) 

Batrix.BuItCh,  zhat,  zhat) ; 

—  INNOVATION  (NU  -  Z-ZHAT) 

aatrix.BubCz,  zhat,  nu) ; 

—  STATE  PREDICTION  COVARIANCE  (P  -  F*P*FT+Q) 

aatrls.aultCl .  p,  teiapi); 
■atrix_BuIt(teaipl,  ft,  t«ap2) : 
aatrix.addCteapZ,  q,  p): 

—  INNOVATION  COVARIANCE  (3  •  H*P«HT-fR) 

Matrlx_ault(h.  p,  tempi); 
■atrix_MUlt(tsMp.l,  ht,  teBp2): 
■atriz_a(ld(taaf2,  r,  s)  ; 

—  FILTER  GAIN  (W  -  P*HT*SI) 

—  Batriz_inv(a,  ai,  teapl);  — old 
■atrix.liiv(B,  si,  Ibb)  : 

■atrix.BultCp,  ht,  tsnpl) ; 

Matrix.ault (teapl,  si,  s) ; 

—  UPDATE  STATE  COVARIANCE  (PN  -  P-W*S*WT) 

aatrix_tranBpose(w,  st): 
aatrix_ault(«,  s,  teapl); 
aatrix.Bult (teapl,  «t,  teBp2); 
Batrix.Bub(p,  t«iap2,  pu); 
p.asBignd,  1,  pn.indexd,  1)); 
p.asaignd,  2,  pn.indexd,  2)); 
p.aaBign(2,  1,  pn.iiic<ax(2,  1)); 
p.aaaign(2,  2,  pu.lndrx(2,  2)); 

—  UPDATED  STATE  ESTIMATE  (XHATN  -  XHAT+W*NO) 

Batrix_Biilt(*,  nu,  tempi); 
BBtrix.add(xh3t,  teapl,  zhatn); 
xbatold.asaignd,  1,  xbatn.indez(l,  1)); 
zbatold.aaaign(2,  1,  xbatn.indez(2,  1}); 

k  :«■  k  f  1 
end  loop; 


If  content  (ddt)  then  --  if  stmteaant  for  debugging/deeelopaant 

put ("graph") ; 

graph. print 0  —  print  loop  result 

end  if; 

“  PLOT  ROUTINE  FOR  OUTPUT  DATA 
ngr  :■  13; 

naaeg.aaaignd,  "k"); 
nanag. assign (2,  "x  truth"); 
narag. assign (3,  "y  truth"); 
naaeg.aasignd,  "z  aaaaured"); 
naaeg.ABBignO,  "y  aeaaured"); 
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naaag.aesign(6,  "x  estiaata"): 
naBeg.assign(7,  "y  estiaata") : 
naaeg.^sBignCS,  "pll,  x  covar") : 
nemeg.aasignOt  "p22,  y  coTax"); 
naaeg. assign (10.  "epsilon"); 
naaeg.assignCll,  "ztilde"); 
naneg.aoBign(12i  "aaas  noise  x“) ; 
naaeg.assign(13,  "aeas  noise  y"); 

H  content (ddt)  then  —  il  stataaant  for  dabugging/darelopaent 

putC'naaeg")  ; 
naaeg.printO 
end  if; 

iopt  1; 

npt  :■  73;  —  related  to  c  above 

--  the  cidl  output  stateaent  is  loraatO 
—  looks  like  write ()  can  also  be  used 

loraatClS  ,""d  "d  "d  *X".  contant(ngr) .  content(npt) ,  content (iopt) ) ; 

—  vrite(8)  (naaeg>indez(j) ,  j  1.  ngr)  —  note  FORTRAN  use  of  assignaect  here 

j  li 

loraatdS.  ""a  "d  "X".  naaeg.  index  ( j) ,  content  (ngr)  ) ; 
j  li 

k  1; 

loraatdS,  "~d  "d  *d  *X">  graph,  index  (content  ( j) .  content(k)),  contaut(npt) ,  content(ngr)) 
ioraat(19  ,""d  "d  "d  "X".  contant(ngr) ,  content(npt) ,  content ( iopt) ) ; 
j  !-  1; 

loraat(f9,  ""a  "d  "X".  naaeg. index(j),  content (ngr) ); 
j  li 

k  1; 

ioraat(19,  "~d  "d  *d  *X".  graph.indez(cQntent(j) ,  content(k)),  content(npt) ,  content(ngr)) 

“  CLOSE  DATA  FILES 
close(f8); 
close(f9); 
close(ilO) ; 
closa(lll) ; 
clo8e(f 12) ; 
close(f 13) ; 
cloaa(114) ; 
closed  IS) ; 
cloBe(fl6); 
close (f 17) I 

—  close (118);  —  this  was  not  used 

—  close (119);  --  this  was  not  used 

close(120) ; 

closed21) ; 
close(122) ; 
closs(123) ; 
closed24) ; 
cloBe(126) ; 

(> 

end  let 
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